10 Jun
2015
10 Jun
'15
12:42 a.m.
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: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol