==> On Thu, 22 Dec 2005 07:09:23 -0600, Alexander Lazarevich <[EMAIL PROTECTED]> 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
