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
|