If you get any i/o problems with the library due to a hardware problem all the
scratch tapes can get pulled into one storage pool, get a little data written
to them, then marked as read-only. If you have 9999 or more tapes suddenly used
up, you'll be left with a lot of clean up. Like manually migrating data from
all the tapes that have a tiny bit of data written to them, then setting them
back to scratch.
If you know roughly how much data is written to tape on a daily basis, or
weekly, or monthly basis, you can estimate how many tapes you use. If you are
not sure, you can estimate on the high end... even on the very high end.
Setting maxscratch to a lower threshold will allow you to become aware of a
hardware problem sooner. If you notice you run out of scratch tapes sooner than
expected, you can check if several tapes are set to read-only with little data
written to them. Not such a big deal with it's only 10 tapes or even 100
tapes... but if it's 10000 tapes, it'll be a pretty big cleanup effort.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf Of
Karel Bos
Sent: Monday, October 13, 2014 9:59 AM
To: ADSM-L AT vm.marist DOT edu
Subject: Re: [ADSM-L] maxscratch
Would use a number a bit higher than 9999 as we had stgpools with 20-30k
volumes in it.....
2014-10-10 15:34 GMT+02:00 Prather, Wanda <Wanda.Prather AT icfi DOT com>:
> Just pointing out a more common use of maxscratch that I see at
> smaller customers, which is in conjunction with collocation.
>
> If you have collocation set to node (or filespace), then TSM is going
> to try and put each node (or filespace) on a separate cartridge.
> So if you have a smaller library, with 60 slots you can use for a
> storage pool, but 120 clients to back up, you set maxscratch to 60 and
> TSM will stack 2 nodes per cartridge.
>
> If you aren't using collocation, or have some other reason for
> limiting cartridge use, you can just set maxscratch to 9999.
>
> W
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Thomas Denier
> Sent: Thursday, October 09, 2014 8:56 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] maxscratch
>
> If scratch tapes are also used for purposes other than storage pool
> volumes, such as database backups, the sum of the maxscratch values
> should be a bit less than the number of volumes in the library.
>
> Thomas Denier
> Thomas Jefferson University Hospital
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of David Ehresman
> Sent: Thursday, October 09, 2014 8:38 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] maxscratch
>
> Eric,
>
> That is correct. If you use maxscratch, it should be set to the total
> number of volumes you want a particular storagepool to use. If you
> have multiple storagepools sharing a tape library (virtual or not),
> the sum of their maxscratches should equal the number of volumes in the
> library.
> Using maxscratch in this way lets you forecast when you will need
> additional volumes. Alternatively, you can set maxscratch to a high
> number and not worry about it; you however lose the information about
> how soon you might need to add new volumes.
>
> David
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Loon, EJ van (SPLXM) - KLM
> Sent: Thursday, October 09, 2014 6:54 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] maxscratch
>
> Hi Steven!
> So if I understand your explanation correctly, for a storagepool used
> by one server only, the maxscratch should always be equal to the total
> amount of volumes in this pool? So when adding new scratches, one has
> to raise the maxscratch with an equal amount?
> Kind regards,
> Eric van Loon
> AF/KLM Storage Engineering
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Steven Langdale
> Sent: donderdag 9 oktober 2014 10:20
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: maxscratch
>
> Eric
>
> It's the max number of vols that can be used from the scratch pool by
> the particular stgpool. so in your instance (assuming you have a
> single stgpool with all 4000 private takes in it AND it got them from
> the scratch pool), if you set it to 1000 you won't be able to use
> anymore new scratch tapes until the usage goes below 1000.
>
> You can look as it as a way to stop a single stpool stealing all of
> the scratch tapes.
>
> Steven
>
> On 9 October 2014 08:53, Loon, EJ van (SPLXM) - KLM
> <Eric-van.Loon AT klm DOT com
> >
> wrote:
>
> > Hi guys!
> > I never used the maxscratch value for our VTL libraries, but I'm
> > just wondering how it works.
> > From the TSM Reference manual:
> >
> > MAXSCRatch
> > Specifies the maximum number of scratch volumes that the server can
> > request for this storage pool. This parameter is optional. You can
> > specify an integer from 0 to 100000000. By allowing the server to
> > request scratch volumes as needed, you avoid having to define each
> volume to be used.
> >
> > What is meant by scratch volumes here? The total amount of scratch
> > tapes when you start with an empty TSM server or the amount of
> > scratches in the current situation?
> > For instance, I have a server with 4000 private tapes and 1000
> > scratch tapes. Should I set it to 1000 or 5000?
> > Thanks for your help in advance!
> > Kind regards,
> > Eric van Loon
> > AF/KLM Storage Engineering
> > ********************************************************
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> > If you are not the addressee, you are notified that no part of the
> > e-mail or any attachment may be disclosed, copied or distributed,
> > and that any other action related to this e-mail or attachment is
> > strictly prohibited, and may be unlawful. If you have received this
> > e-mail by error, please notify the sender immediately by return
> > e-mail, and delete
> this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> > and/or its employees shall not be liable for the incorrect or
> > incomplete transmission of this e-mail or any attachments, nor
> > responsible for any
> delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> > registered number 33014286
> > ********************************************************
> >
> >
> ********************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only.
> If you are not the addressee, you are notified that no part of the
> e-mail or any attachment may be disclosed, copied or distributed, and
> that any other action related to this e-mail or attachment is strictly
> prohibited, and may be unlawful. If you have received this e-mail by
> error, please notify the sender immediately by return e-mail, and delete this
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for any delay
> in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with
> registered number 33014286
> ********************************************************
>
> The information contained in this transmission contains privileged and
> confidential information. It is intended only for the use of the
> person named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution or
> duplication of this communication is strictly prohibited. If you are
> not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.
>
> CAUTION: Intended recipients should NOT use email communication for
> emergent or urgent health care matters.
>
>
This message and any attachments are solely for the use of intended recipients.
The information contained herein may include trade secrets, protected health or
personal information, privileged or otherwise confidential information.
Unauthorized review, forwarding, printing, copying, distributing, or using such
information is strictly prohibited and may be unlawful. If you are not an
intended recipient, you are hereby notified that you received this email in
error, and that any review, dissemination, distribution or copying of this
email and any attachment is strictly prohibited. If you have received this
email in error, please contact the sender and delete the message and any
attachment from your system. Thank you for your cooperation
|
