11 Aug
2016
11 Aug
'16
6:43 p.m.
On 08/11/2016 02:08 PM, Stan Sieler wrote:
One important thing to do, depending upon your
operating system and
tape drive characteristics of course, is to issue read requests for a
few bytes more than you expect ... because with some OSs and some
kinds of drives, if you ask for X bytes and the record has more than
X, you'll quietly get X and the rest will be discarded. (That came
up in a court case where I was an expert witness ... an alleged
'expert' had copied a 9-track tape (badly) and lost data because the
records were larger than he expected, and his copying tool didn't
have that simple safeguard in it.)
If you're using a SCSI drive, that's pretty simple to read the tape in
"variable" block mode, leaving a generous buffer--the result sense
status will tell how much was read.
Pertec drives are super-stupid, so you start reading and counting bytes
until the block ends.
A second thing is to be somewhat aggressive in reading
the 'end' of
the tape. The backup tapes I frequently encounter supposedly end with
two EOFs in a row ... except for a few that happen to have extra data
past that point :) (Of course, with 9 track tapes, you run the risk
of going off the end!)
I've had a couple of tapes with "fooler" double file marks. The first
was a zero-length file--had I thought to look at the block count
(000000) in the HDR label, it would have been obvious.
The second was a bit more involved--the tape started off in 6250 GCR
mode and read to EOF just fine. However, I picked up perhaps half a MB
of data, which seemed too little for a 10" reel. Rewind, manually set
the density to 1600 and read, letting the drive skip over what was now
interpreted as erased tape. What followed was a complete half-reel of
1600 data that would have been lost. My guess is that someone had an
"oh sh*t" moment, reset the density manually and finished the tape off
in the lower density as intended. I don't know if this could be
recovered with most SCSI streamers, which don't allow density changes
except at BOT.
War stories...I love 'em.
--Chuck
(Yes, that begs the question...if you're archiving a tar tape ... do
you *want* the data past the first EOF? (Which could be part of a
prior (and longer) tar, or something else.)) (And then there are the
people who put tar after tar after tar on the same tape :)
Stan
--
--Chuck
-------------------------------------------------------------
"The first thing we do, let's kill all the spammers."