It has more to do with LTO tapes becuase they don't handle the
"little files spoon fed one at a time" as well as say 3570 tapes.
I have both here and can compare. The root cause is TSM design
though.  (I still like LTO, it is really great in my view!  Now that I 
understand what's happening, I just adjusted things so this one
problem is not much of a problem.)

They are correct, keeping on disk will speed up restores especially
if you do a lot.  But balance this out for each sites requirements.
If you don't do many restores and the reclamation is difficult
to complete, then keep less on disk.  Similar to other "tuning"
that we do with TSM.

David Longo

>>> ebrodeur AT SERTI DOT COM 06/26/02 05:03PM >>>
I did try it and it does move a lot faster..  So this has nothing to do
with the fact that my diskpool is on a SAN drives right?  So keeping data
on diskpool is not a good idea in small installations?  I was told by
Tivoli techs to try and keep a couple of days of backups on disk if
possible to speed up restores...  Is this not a good idea?

Thanks for the help,

Etienne Brodeur




Bill Boyer <bill.boyer AT VERIZON DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/26/2002 11:55 AM
Please respond to "ADSM: Dist Stor Manager"

        To:     ADSM-L AT VM.MARIST DOT EDU 
        cc:
        Subject:        Re: Slow Reclamation from disk


When the primary location of a file is in a primary DISK random access
storage pool, then this is "working as designed." (That's the answer we
got
from Tivoli)  In this case the reclamation task processes 1 file at a time
per transaction. When the primary storage pool is a SEQUENTIAL media
(either
tape or FILE) then the files are batched up by the
MOVEBATCHSIZE/MOVESIZETHRESH parameters. Move the files to a SEQENTIAL
primary pool before running reclamation.

Bill Boyer
DSS, INc.