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:[EMAIL PROTECTED] On Behalf > Of Schneider, John > Sent: Tuesday, November 04, 2008 12:35 PM > To: [email protected] > 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: [EMAIL PROTECTED] > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of > lindsay morris > Sent: Tuesday, November 04, 2008 11:57 AM > To: [email protected] > 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 > [EMAIL PROTECTED] > > > > On Nov 4, 2008, at Nov 4, 12:21 PM, Bos, Karel wrote: > > > No :) > > > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On > > Behalf Of > > Thomas Denier > > Sent: dinsdag 4 november 2008 18:14 > > To: [email protected] > > 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.
