Restoring lots of smaller files can be a problem on two fronts.  The
other problem, besides the one that Kelly mentioned, comes about when
restoring small files from tape.  IF the files are not contiguous on
tape, then TSM will spend time spacing (skipping) down the tape.  We
ran some benchmarks on restoring small files and found this made
quite a difference.  One sample benchmark was to restore files off of
a live production tape.  The other benchmark was to restore the same
files off of another tape that had been newly created (thus the files
were all continguous).  The second benchmark ran much faster.  This
was using LTO2 tape technology btw, and several hundred thousand
files, to Solaris and AIX clients.  Restoring the same set of files
off of serial-access disk volumes was somewhat faster than the second
benchmark, but not significantly.  However, using serial-access disk
volumes (or VTLs) should consistently perform better than tape,
assuming that your average tape does get "pockmarked" over time,
meaning that the files you want to restore will end up not all being
continguous.

I do not know what affect a client-side bottleneck will cause tape
I/O to slow down and drop out of streaming mode.  This is another
concern that I've had but have been unable to test and
validate.  When/if a tape drive drops out of streaming mode, it will
backhitch, which takes time.  LTO2+ has variable speed technology,
which helps, but I think only to a limit.  I think there may still be
a point where if the data is being read too slowly, the drive will
stop streaming.

my 2 cents...  I'd love to see an in-depth detailed study of this stuff.

At 11:43 AM 5/23/2007, James Choate wrote:

The disk on the client is an UltraSCSI 320 mirrored.  The file
characteritics of the client are 50,000 + files.  Smaller files, but not a lot.

--
Paul Zarnowski                            Ph: 607-255-4757
Manager, Storage Services                 Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu