Hot Diggety! Coats, Jack was rumored to have written:
> Try 3 minute :( to get a LTO loaded and started spinning ... great for bulk
> store, but not up to 'interactive' response needs :( ... Using LTO for HSM
> would seem counterproductive IMHO.
3 minutes?! Something sounds wrong there. I've got a 3584 with 12 LTO
drives attached to host system via SCSI, and it takes 3-9 seconds to
have the robot fetch the tape from storage slot, move it to drive, load
it in the drive, and about 46 seconds to read the volser on the tape and
other mount-related processing, for a total of about 55 seconds from
issuing command to load to start using a tape.
We've got a L32 and D32 frame; guess it could conceivably be a little
longer in worst case scenarios if had a decked out setup (one L32 and
five D32s) but I can't see it being much more than 1m to 1m10s or so.
However, that 55 seconds is a little painful in certain situations.
For example:
client->disk stgpool (10MB max)->tape stgpool
Client sends data to TSM server
As long as client data is < 10MB, streams to disk pool
Soon as client sends a 11 MB or 500 MB file, then...
TSM fetches a tape, mounts it (55 sec wait)
TSM starts writing file to tape
Once done, TSM dismounts the tape (!)
Client continues sending data
If it hits another >10MB file, the whole mount-write-dismount process
repeats. This results in a significant performance hit from all the
mounts/dismounts. To alleviate this, I've set the node's KEEPMP option
to YES, so it ends up mounting the tape once on first access, then keeps
it mounted throughout the entire client run so that we get no more
subsequent 55 sec mount delays. When does it dismount the tape? After
the tape retention in drive period expires, but usually the next client
session grabs the same tape if it's got free space.
The above was with a TSM 4.2 setup; I just installed TSM 5.1, so I've
got to retest to see if this is any different without the KEEPMP option
being enabled.
Anyway, I'd strongly urge you to get that 3 minute wait looked at!
-Dan
|
