==> On Thu, 22 Dec 2005 07:09:23 -0600, Alexander Lazarevich <alazarev AT 
ITG.UIUC DOT EDU> said:


> Thanks for the responses all, but it's not a tape mounting issue. I wasn't
> clear enough in my original post, but I am watching the actlog while the
> restore is taking place, and I'm sitting next to the library, so I can
> tell when it's doing anything: remounting, rewinding, etc. What I'm
> saying is this:

> The server is restoring a single 32GB file, and starts doing so at
> 30+MB/sec. At some point, DURING the restore of that SAME 32GB file, the
> server suddenly slows down the restore, to 200-300K/sec. The server has NOT
> switched tapes, and is NOT rewinding even the SAME tape. It is still
> restoring that same 32GB file, but suddenly does so at a slower speed.


32GB writes aren't all that common; have you experimented with the client
architectures' behavior under straight e.g. dsmfmt of a 32G file?

Clearly, this kind of write behavior will put you way in a corner of the
performance domain; maybe some put-off parity calculation comes due after N GB
of serial write?  Areas within the file which compress better or worse would
reasonably make a difference in your speed, but not that much, I think.

How long are the stutters and the periods of good speed?  Seconds?  Minutes?
Is tape backhitch plausible, or is that what you mean by rewinding?


- Allen S. Rout