Tape Imaging

[Chuck Guzis]

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."