Veritas-bu

Re: [Veritas-bu] More tapes than cap space on eject

2009-06-19 12:37:36
Subject: Re: [Veritas-bu] More tapes than cap space on eject
From: scott.george AT parker DOT com
To: veritas-bu AT mailman.eng.auburn DOT edu
Date: Fri, 19 Jun 2009 12:33:15 -0400
I want to pass my gratitude on to Neil; this was the fix for my issue. For 
those who may be concerned, the NetBackup server starts the 5 minute 
counter when it gives the message to empty the cap.  For a server that has 
to communicate to ACSLS to fill 2 - 39 slot caps, the timer will expire 
before the caps are actually full.  I extended the MAP_CONTINUE_TIMEOUT 
parameter in vm.conf to 2400 and received good success with a 91 tape 
eject.

Thanks again Neil!




>I only have experience with SCSI-controlled TLD and TL8 libraries, but 
this
>might be useful...

>Try ejecting a large batch of tapes manually and see how it behaves when 
the
>cap fills:

>vmchange -multi_eject -w -res -ml $EJECT_LIST -rt $ROBOT_TYPE \
>        -rn $ROBOT_NUM -rh $ROBOT_HOST


>You can add this setting to vm.conf to control how long vmchange waits 
for
>confirmation when the cap is filled (I think the default is 5 minutes).

>MAP_CONTINUE_TIMEOUT = 1200

>The way this works is that if no one acknowledges that the cap has been
>emptied and reinserted before the timeout expires, then the library 
control
>daemons die and vmchange aborts any further processing and exits with an
>error.

>HTH,
>Neil



On 6/12/09 11:17 AM, "scott.george at parker.com" <scott.george at 
parker.com>
wrote:

> No, they are right on it, because they initiate the eject with the
> deferred eject.  What happens is the vault runs and does all of its 
dupes
> and the finishes without ejecting anything.  When they notice the vault 
is
> done, they expand out "Vault Management" down to the job itself and 
right
> click --->Deferred Eject.  It then kicks out all of the tapes, well, 78 
of
> them.  They are really good on their timing (like within 30 minutes of 
the
> vault finishing). The problem is, when they empty both caps and close 
them
> back up, the remaining tapes don't eject, and the deferred eject job 
hangs
> for a long time (at least an hour).  It was shorter in 6.0.  Today, we
> just killed the job and ran reports from vltopmenu to genterate ftp 
files
> and reports, and ejected the tapes manually.  I tried ejecting 90 tapes
> manually, and only got 38 of them out.  I checked the ACSLS server and 
"q
> req all" showed nothing.  The eject job only showed the 39 tapes 
ejected,
> with the others waiting.  When I emptied and closed the cap, nothing
> progressed.  I ended up killing the eject.
> 
> 
> 
> 
> 
> <Rusty.Major at sungard.com>
> 06/12/2009 02:07 PM
> 
> To
> scott.george at parker.com
> cc
> veritas-bu at mailman.eng.auburn.edu,
> veritas-bu-bounces at mailman.eng.auburn.edu
> Subject
> Re: [Veritas-bu] More tapes than cap space on eject
> 
> 
> 
> 
> 
> 
> 
> We aren't sending that many tapes offsite, but I do have similar issues
> with the ACS libraries hanging in eject mode until the cap is emptied 
and
> then closed in an empty state. I really hate this operation, btw, but we
> utilize the eject notification to email the operators to inform them 
they
> need to go empty the cap asap. Is your crew not getting to it in enough
> time (like hours)? If  ours do not get to it in 3 or 4 hours, or don't
> shut the cap when it's empty, this causes vault to hang up because acsls
> doesn't give the all clear.
> 
> Rusty Major, MCSE, BCFP, VCS ▪ Sr. Storage Engineer ▪ SunGard
> Availability Services ▪ 757 N. Eldridge Suite 200, Houston TX 77079 ▪
> 281-584-4693 
> Keeping People and Information Connected® ▪
> http://availability.sungard.com/
> P Think before you print
> CONFIDENTIALITY:  This e-mail (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited.  If you received this e-mail in error,
> please notify the sender and delete this e-mail from your system.
> 
> 
> scott.george at parker.com
> Sent by: veritas-bu-bounces at mailman.eng.auburn.edu
> 06/12/2009 11:39 AM
> 
> 
> To
> veritas-bu at mailman.eng.auburn.edu
> cc
> 
> Subject
> [Veritas-bu] More tapes than cap space on eject
> 
> 
> 
> 
> 
> 
> 
> 
> All,
> 
> I have a NBU 6.5.3.1 server running AIX. and a STK SL8500 Library with
> dual 39-slot caps, driven by ACSLS.  Our vault jobs are to the point 
where
> 
> they are consistently more than 78 tapes, and when the deferred ejects 
are
> 
> performed, the remaining x-78 tapes will not eject.  We just upgraded to
> 6.5.3.1 on Wednesday from 6.0MP5, which only seemed to prolong the vault
> job.  The same symptoms ocurred in both versions, but 6.5 is really
> waiting for the final tapes to eject (or so it seems).  Based on our
> observations, it appears that this is an ACSLS problem, but I wanted to
> see if anybody had any suggestions on how to know for sure.  We have
> really been ignoring this since the operators were satisfied with 
ejecting
> 
> the remaining tapes manually.  But since the deferred eject is now 
hanging
> 
> until it gets good eject status of the remaining tapes (again, I don't
> know that for sure), this has become a more urgent issue.
> 
> Has anybody seen anything like this before?
> 
> Thank you,
> 
> Scott
> 
> 
> PLEASE NOTE: The preceding information may be confidential or
> privileged. It only should be used or disseminated for the purpose
> of conducting business with Parker. If you are not an intended
> recipient, please notify the sender by replying to this message and
> then delete the information from your system. Thank you for your
> cooperation.
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
<Prev in Thread] Current Thread [Next in Thread>