On 2015-06-10 09:34, Mark J. Blair wrote:
I was looking at a couple of documents describing the Pertec tape interface;
the manual for my Kennedy 9610 tape drive, and a nice reference by a fellow
with a rather familiar name:
http://www.sydex.com/pertec.html
According to my Kennedy manual, issuing a read command causes the drive to
return one block of data. I can see how that would be used in block-oriented
applications in which blocks may be randomly read, written and re-written on
the tape. But most of my magtape experience has been using the tapes in a
streaming mode, such as when reading/writing one or more tar archives separated
by file marks.
Yes. Tapes pretty much always have blocks...
When writing a tar archive on a magtape from a Unix system, is the archive
written as a sequence of fixed-size blocks? Or is the entire tar archive
effectively written as one continuous block which must be streamed with no
repositioning?
Yes, tar uses a fixed block size. You can actually tell it what block
size to use.
Most versions of tar I know use the -b switch for this.
I'm curious because I'm daydreaming about how to build a tape drive interface
controller, and I wonder whether it might need to potentially stream an entire
tape in one go vs. being able to safely assume some maximal block size.
You can pretty much assume that no tape uses larger blocks than 64K. But
you have to expect blocks of pretty much any size below that.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
