2 May
2002
2 May
'02
2:10 p.m.
However, if I notice recovered-reads (or hard errors)
on old 9-track
tapes, I often see fewer recovered reads (or hard errors) if I try
the tape one more time. I assume that going over the heads once
may have knocked off a bit of dust/dirt/something that affected
the tape the first time. Note that I don't discard the
results of the first run until the second run finishes...
hey! Me too!
I've had one tape break during a second run :)
Ouch! Acetate backing?
Go buy a 9-track drive and hang it on your *nix box.
Let me send you a 9-track tape. You read it any way
you want. You send me the tape back.
> Then you go get a second tape, and put the data back on
> any way you want. Then send it to me, and I'll tell you
> if your technique works or not. 
2 May
2 May
2:52 p.m.
Re:
It actually was an element of a trial in Canada that I was
testifying (as an expert witness) at, about 8+ years ago.
Someone had copied a tape whose records were 16 KB long using software
that expected the records to be 8192 bytes longs ... and only asked
for 8192 bytes in each read() request.
Thus, since they didn't ask for 8194 (or more) and notice the extra data,
and they blithely (and incorrectly) assumed that they had copied the
entire tape. Later, they incorrectly/inappropriately used a utility
to try to restore files from the copy, resulting in random pre-existing
disk garbage being left in the second 8K bytes of every 16 KB chunk
of disk file they fetched off the tape copy.
(Why not ask for only 1 byte more? Some systems can't handle an odd
number of bytes in a tape record, and might round up/down in a manner that
you don't expect.)
(P.s.: my guy won)Stan Sieler
sieler(a)allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
BTW, the only
way you can be *SURE* you got all the data on
the tape is if *EVERY* read-request returned fewer characters
than you asked for. E.g., if you did:
bytesread = read(fromfd, buffer, BUFSIZE);
and you get BUFSIZE bytes in, then there's a chance that that
tape record had BUFSIZE + 100 bytes ... and you've just lost
those last 100 bytes.
I *just* recently discovered this, and will incorporate that
into a utility I'll be hosting on the Prime. 
4:15 p.m.
On Thursday 02 May 2002 18:52, you wrote:
Someone had copied a tape whose records were 16 KB
long using software
that expected the records to be 8192 bytes longs ... and only asked
for 8192 bytes in each read() request.
Now i really do find this interesting
Lets scope out some examples to illustrate my focus.
On a floppy or a hard disk as examples you have
pad data inbetween its records these are usually
all FF's constant stream on 1's in other words
then an address mark like FE followed by the header data
Head Sector Cylinder ,, then some more FF's then a start
of data mark the block of data then the CRC .. then all
else is ignored ,, be it artifacts from a prev write ( hub speed jitter )
or whatever .. the controller is looking for its string of a minimum
number of 1's then the FE and so it repeats all round the disk.
During lowlevel formatting you are basically building an image
of this track .. complete with the between sector filler of FFs
amd dumping a whole track at once with the write track command.
These devices are random access, but when you pull the image
off the device using it as a streamer, you are not getting
the filler bytes the address marks or the crc's your getting
only the content of the sectors (soft physical records)
back to back a raw spool off a unix device with a typical
device driver gives you the data without the controler
interested bits off the media.
I would assume that any decent unix driver up to the minimal
expectations of behavior should act the same, including
that for a proper interface to a 9 track tape.
If the record length is varible, then is not the record length
in the block headder ? and should not the driver read
that from the headder then xxx bits of data ?
it would seem that any tape used as a random access
block device, that ever had a record re written would
have garbage (from a prev update of that record)
in the block,
just like on a floppy where this happens all the time,
(jitter again) and the controller simply ignores looking
for its resetting minimal number of FF's and the next
address mark
( im ignoring the hard sector media with a hole for
every sector, but it would still apply in this scope
albeit a bit differently)
Now .. excuse me, but ive been around this stuff
for a long time, and i think ive got a really firm grasp
of the minimal amount of things needed in place for
any data-to-media, data-from-media scheme to work.
So, do i have this right ?
That if i spooled off a 9 track tape, and assuming no
non-recoverable media errors, that i would *not*
get all of the data from all the records and without
trailing garbage and the controler interested bits left out ?
Knowing the proper expected behavior of any unix
driver i could name ... i find this rather ....
well unexpected.
Raymond
8121
days inactive
8121
days old
2 comments
3 participants
participants (3)
-
dquebbeman＠acm.org -
rmoyers＠nop.org -
sieler＠allegro.com