> From: Raymond Moyers <rmoyers_at_nop.org>
> To: classiccmp_at_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_at_localhost>
>
> 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 ?
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.
> 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_at_ucsd.edu
Received on Fri May 03 2002 - 03:02:24 BST