2 May
2002
2 May
'02
8:02 p.m.
From: Raymond Moyers <rmoyers(a)nop.org>
To: classiccmp(a)classiccmp.org
Subject: Re: Tape dumping programs for Unix/Linux..
Date: Thu, 2 May 2002 20:15:37 -0500
In-Reply-To: <3CD16EDB.31791.1013160B@localhost>
On Thursday 02 May 2002 18:52, you wrote:
No. You haven't been around tape drives long enough. The tapes
are not preformatted with block headers. They are written sequentially.
In general, a tape drive can only record forward and add data beyond
whatever has already been written.
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
Only some very special tapes with extra tracks for tape mark
information can be reliably used as random-access block devices.
The classic example is DECtape, 3/4 inch wide on 3 inch reels.
Pre-formatted into blocks of 129 12-bit words or other interesting
combinations.
( 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 ?
No.
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 ?
Your tape-reading program might truncate all block lengths to
the length that it was "expecting". Or just quit after the
first file instead of reading all the files on the tape.
Knowing the proper expected behavior of any unix
driver i could name ... i find this rather ....
well unexpected.
Nobody has said that Unix has well-designed tape drivers.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu