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: [EMAIL PROTECTED]
