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 DOT com" <scott.george AT parker
DOT 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 DOT com>
> 06/12/2009 02:07 PM
>
> To
> scott.george AT parker DOT com
> cc
> veritas-bu AT mailman.eng.auburn DOT edu,
> veritas-bu-bounces AT mailman.eng.auburn DOT 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 DOT com
> Sent by: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> 06/12/2009 11:39 AM
>
>
> To
> veritas-bu AT mailman.eng.auburn DOT 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 DOT 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/listin
> fo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
