Is there a way to check for write errors on the tape, where it maybe had to
skip sections of bad media when creating the file on tape? or, possibly
read errors when trying to get the file from tape?
"Allen S. Rout"
<[EMAIL PROTECTED]>
Sent by: "ADSM: To
Dist Stor [email protected]
Manager" cc
<[EMAIL PROTECTED]
.edu> Subject
Re: [ADSM-L] restore speed question
12/22/2005 09:42
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[EMAIL PROTECTED]
.edu>
==> 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
