Pertec Tape Drive Interface Musings

Dave G4UGM dave.g4ugm at
Wed Jun 10 02:47:03 CDT 2015


  Traditional 9-track tapes are always written block-by block with a "short"
gap between the records, WikiPedia say 0.6" for 1600BPI which sounds about
right. From what I remember as tapes are not the most reliable medium the
process was to have the read head after the write head so the tape could be
read and checked as it was written. If an error was returned the "system"
would backspace, erase the bad block to create a "long gap" and the try
again. Looking at the first MAN page for TAR I found it says it writes
20x512 byte blocks so 10K blocks, i.e. about 6.4" long. That means a "waste"
of 10% of the tape in gaps, assuming the tape is perfect.  You can write
longer blocks but then the amount of wastage when you write a bad block goes

So I guess to answer your question. Operating systems and tools expect a
block level interface to tapes. You need to duplicate this in your


> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at] On Behalf Of Mark J.
> Blair
> Sent: 10 June 2015 08:34
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Pertec Tape Drive Interface Musings
> I was looking at a couple of documents describing the Pertec tape
> the manual for my Kennedy 9610 tape drive, and a nice reference by a
> with a rather familiar name:
> 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
> 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.
> 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?
> 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.
> --
> Mark J. Blair, NF6X <nf6x at>

More information about the cctech mailing list