ADSM-L

Re: [ADSM-L] Offsite reclamation problem

2008-11-04 15:18:51
Subject: Re: [ADSM-L] Offsite reclamation problem
From: Howard Coles <Howard.Coles AT ARDENTHEALTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 4 Nov 2008 13:02:09 -0600
Yes, look up the "mount options" option in the device class (In ISC).
You can set this to a hard number, such as in the case we've been
speaking of to 8 or 9 (for 2 or 1 drive free), or allow TSM to reserve a
drive by setting it to "Up to the number of online drives in the
library". 

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Schneider, John
> Sent: Tuesday, November 04, 2008 12:35 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Offsite reclamation problem
> 
> All,
> 
> I have often heard people say, as Linday just did, "keep at least one
> drive free for user restores".  Is there in fact any way to cause TSM
> to
> leave one tape drive always free, so no other tape process besides a
> restore can access it?
> 
> In our environment, we have 10 TSM servers sharing a tape library with
> 24 LTO4 tape drives.  Each day they all have to accomplish the entire
> daily cycle of backup stgpools, db backups, migrations, reclamations,
> etc. and these are driven by perl scripts on each of the 10 instances.
> I cannot think of any reasonable way for all of these to get their
jobs
> done as quickly as possible, but somehow remain sensitive to what all
> the other instances need to do so that they won't use all the tape
> drives available.  We use most of the 24 tape drives most of the time
> as
> it is.
> 
> I can think of some extremely inefficient ways, like making all the
> backup storage pools wait until all of them are finished, then
> everybody
> goes on to the next step, etc.  But this will inevitably cause long
> delays where half the tape drives are sitting idle waiting for one or
> two slow instances to finish before going on to the next step.  We
> can't
> afford that sort of waste in the schedule.
> 
> Is there some feature to do this that I missed?
> 
> Best Regards,
> 
> John D. Schneider
> Phone: 314-364-3150
> Cell: 314-750-8721
> Email:  John.Schneider AT Mercy DOT net
> 
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> lindsay morris
> Sent: Tuesday, November 04, 2008 11:57 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Offsite reclamation problem
> 
> Lots of people have a best-practice of always keeping at least one
> drive free for user restores.
> That minimizes the problem.
> 
> It makes users happy too, because
> even though a restore does pre-empt another task, it may take TSM 40
> minutes to finish the reclamation it was working on and give up the
> drive.
> 
> So the user has to sit waiting for far too long (in some cases).
> 
> 
> ------
> Lindsay Morris
> Principal
> www.tsmworks.com
> 919-403-8260
> lindsay AT tsmworks DOT com
> 
> 
> 
> On Nov 4, 2008, at Nov 4, 12:21 PM, Bos, Karel wrote:
> 
> > No :)
> >
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf Of
> > Thomas Denier
> > Sent: dinsdag 4 november 2008 18:14
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Offsite reclamation problem
> >
> > We have a 5.4.2.0 TSM server running under mainframe Linux. We have
> > five
> > tape drives available for our primary tape storage pool and five
tape
> > drives available for our copy storage pool. We run offsite tape
> > reclaimation with 'maxproc=5'. If a client runs a restore while off
> > reclamation is going on, TSM will take a tape drive away from
> > reclamation. This is done by cancelling a reclamation process,
rather
> > than having a process go into mount point wait. TSM does not start a
> > replacement process when this happens. A restore that runs for a
> > couple
> > of minutes can leave a pair of tape drives sitting idle for hours.
Is
> > there any configuration setting or release level upgrade that will
> > cause
> > TSM to handle this situation more intelligently?
> >
> > <disclaimer.txt>
> This e-mail contains information which (a) may be PROPRIETARY IN
NATURE
> OR
> OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only
> for the
> use of the addressee(s) named above. If you are not the addressee, or
> the
> person responsible for delivering this to the addressee(s), you are
> notified
> that reading, copying or distributing this e-mail is prohibited. If
you
> have
> received this e-mail in error, please contact the sender immediately.