Next time it is hung, do run the undocumented 'show threads' command and you
will see the hung drives waiting for the thread to be released on the hung drive
before the next mount can occur. This was written up pretty well and can be
found in a search of the www.tivoli.com/support information base.... whatever is
occuring is annoying....
George Lesho
Storage Admin
AFC Enterprises
David Longo <David.Longo AT HEALTH-FIRST DOT ORG> on 02/08/2001 02:05:01 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: George Lesho/Partners/AFC)
Fax to:
Subject: Re: tape mount retention behaviour
I also have a 3575 and most of thsi "dismounting" may be due to rebuilding the
VCR on the tape header. (This is something used by Magstar tapes). If you
check actlog during this time you will propbably see an entry for the tape that
"dismount may be delayed" due to rebuilding the VCR on the tape. I have easily
seen this take 10 minutes when it happens. I have probably had a few go 20-30
minutes.
Priorities can't bypass this - I think it is more a tape media/drive issue than
*SM and it has to complete or your tape may not be usable.
David B. Longo
System Administrator
Health First, Inc. I/T
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH 321.434.5536
Pager 321.634.8230
Fax: 321.434.5525
david.longo AT health-first DOT org
>>> glesho AT AFCE DOT COM 02/08/01 02:38PM >>>
I have had problems with tapes that won't dismount immediately and in fact take
over 1/2 hour to dismount... they will show "dismounting" if you do a 'q mount'.
Basically, there is a problem with the thread processes and this was a known bug
that was supposed to be fixed with TSM 3.7.4 (supposedly). I am runnin 3.7.3.6
and have this problem if I halt / start the system and reclamation puts all 6 of
my drives in my 3575 L32 into use at once. Then , as I said, they will not
dismount until the thread processes time out... I asked Tivoli support what
alternatives I had and they suggested upgrading to 3.7.4 or newer version of
TSM.
George Lesho
Storage Admin
AFC Enterprises
Joel Fuhrman <joelf AT CAC.WASHINGTON DOT EDU> on 02/05/2001 08:17:44 PM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: George Lesho/Partners/AFC)
Fax to:
Subject: Re: tape mount retention behaviour
I'm using ACSLS (STK). When I'm doing something like a simultaneous
migration of 3 storage pools to 2 tape drives, the behavior I observed, in
the past, is that when the first migration completes, it tape was not
unmounted until the mount retention period expires. Thus the third
migration has to wait the mount retention period before it could get a tape.
I get around this by reducing the mount retention to zero during those
process that create tape queueing. I will have to check if this behavior
still exists in my current level.
On Mon, 5 Feb 2001, Alex Paschal wrote:
> Joseph, Joel, out of curiosity, is there any chance are you using EXTERNAL
> library types?
>
> I know TSM will dismount an idle volume if it needs a mountpoint in 3494's
> as Kent has pointed out. I think it may behave the same way with a SCSI
> library type also.
>
> In fact, on a hunch, I just now checked my TSM 3.7 Admin Guide, Appendix A,
> External Media Management Interface Description. The valid return codes for
> a Volume Mount Request are:
> SUCCESS
> DRIVE_ERROR
> LIBRARY_ERROR
> VOLUME_UNKNOWN
> VOLUME_UNAVAILABLE
> CANCELLED
> TIMED_OUT
> INTERNAL_ERROR
> There is nothing that indicates waiting for a mount point. That could
> account for idle volumes not being dismounted; TSM doesn't know that the
> External Library Manager is waiting for a mount point.
>
> Alex Paschal
> Storage Administrator
> Freightliner, LLC
> (503) 745-6850 phone/vmail
>
> -----Original Message-----
> From: Kent J. Monthei [mailto:Kent_J_Monthei AT SBPHRD DOT COM]
> Sent: Monday, February 05, 2001 5:20 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: tape mount retention behaviour
>
>
> We also use ADSM 3.1.2.20 (for Solaris) with IBM 3494 Libraries and have
> observed behavior consistent with that described by Joseph in the original
> email
> - an idle mount will be immediately dismounted if/when there is another
> mount
> pending and no other drive is available. However, we also recently dropped
> the
> mount retention from the default 60 minutes down to just 5 minutes.
>
> Under what scenarios (or rationale) does it make sense to force tapes to
> remain
> mounted more than 5 minutes after a client backup session has completed?
>
> -Kent M., GSK
>
>
>
>
>
>
> joelf AT cac.washington DOT edu on 05-Feb-2001 19:57
>
>
>
> Please respond to ADSM-L AT vm.marist DOT edu
>
> To: ADSM-L
> cc: (bcc: Kent J Monthei/CIS/PHRD/SB_PLC)
> Subject: Re: tape mount retention behaviour
>
>
>
>
> I thought it always worked this way. At one time I was going to put in a
> request to have two mount retention times. One for when there are no
> pending request for a drive and the other for when there are pending
> request.
>
> On Mon, 5 Feb 2001, Joe Faracchio wrote:
>
> > I recently upgraded from 3.1.2.20 to 3.7.2.0
> > and notice a very annoying behaviour.
> >
> > The system keeps an idle tape mounted for the full retention period
> > specified despite the pending mounts that are waiting.
> >
> > when / where will this be fixed???
> >
> > thanks ... joe.f.
> >
> > Joseph A Faracchio, Systems Programmer, UC Berkeley
> >
>
"MMS <health-first.org>" made the following
annotations on 02/08/01 15:09:55
------------------------------------------------------------------------------
This message is for the named person's use only. It may contain confidential,
This message is for the named person's use only. It may contain confidential,
proprietary, or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in error,
please immediately delete it and all copies of it from your system, destroy any
hard copies of it, and notify the sender. You must not, directly or indirectly,
use, disclose, distribute, print, or copy any part of this message if you are
not the intended recipient. Health First reserves the right to monitor all
e-mail communications through its networks. Any views or opinions expressed in
this message are solely those of the individual sender, except (1) where the
message states such views or opinions are on behalf of a particular entity; and
(2) the sender is authorized by the entity to give such views or opinions.
=======================================
|
