Be careful about extrapolating 3590 concepts into other areas...
I have seen no published information to suggest that the 3592 tape
utilizes a Volume Control Region (VCR) as does the 3590. The design
of the 3592 cartridge borrows from the LTO cartridge design in
incorporating a 4 KB Cartridge Memory (CM) chip for the recording of
various information about the cartridge and media. 3592 tape load
time is improved over 3590 load time in that the 3592 can read its CM
in parallel during the loading process, as opposed to the 3590 having
to position to and digest VCR info before proceeding with the load.
If 3592 tape errors are detected, this information is recorded on the
CM to allow the next drive to learn that the tape is "degraded".
Taking a long time to traverse a given area of tape is typically a
manifestation of retries, incited possibly by media defects or
environmental contaminants, as well as other issues previously
mentioned in this thread. There is obviously no "linear scan" issue
where a single file is being operated upon.
I would advise taking a comprehensive look at your tape
environment...everything from air quality to drive microcode to brand
media quality. You might cut open a particularly bad cartridge and
perform a post mortem. (In doing this on a bad 3590 cartridge I
discovered that the tape was actually rippled as it came from the
manufacturer.)
Richard Sims
On Jul 31, 2006, at 3:09 PM, Thomas Denier wrote:
-----"Survoy, Bernard J" <bernard.survoy AT sun DOT com> wrote: -----
Sounds like you have an issue on some volumes with the VCR (volume
control region). This structure is used (among other things) to
support high speed search operations. If the VCR is invalid or
damaged, the drive will go into a low speed (essentially sequential
scan) until you get to the data location you want (takes forever,
if you look at the drive, it looks like it is reading tape). I know
on Sun/STK enterprise class drives, we have a similar structure
called the MIR (media information record); this structure is
rebuilt during the sequential scan up to the point where you
successfully locate the data. A subsequent access beyond this
point is will rebuild the structure from that point forward.
Just how slow is the linear scan? I am in the process of executing
a 'move data' for a problem volume. The process moved 22 gigabytes
in the first hour or so, and has ostensibly spent almost 5 hours
working on a single 4.7 gigabyte file. How long should I wait for
this one file before I conclude that I have a problem other than
lost VCR information?
What do I do if I decide at some point that the 'move data' is a
lost cause, and want to try 'restore volume' instead? The 'cancel
process' command is cleverly designed to be useless in this sort
of situation; the process will not end until it finishes the current
file. Is there a way to get TSM to stop a data movement process
inmid-file?
|
