Pertec Tape Drive Interface Musings

[Dave G4UGM]

> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Johnny
> Billquist
> Sent: 10 June 2015 09:39
> To: cctalk at classiccmp.org
> Subject: Re: Pertec Tape Drive Interface Musings
> 
> On 2015-06-10 09:47, Dave G4UGM wrote:
> > Mark,
> >
> >    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 up.
> 
> I don't think it really is that you have a long gap when you rewrite a "bad"
> block per se. 

What else do you get then? I can see from the IBM 2400  manual here:-

http://bitsavers.trailing-edge.com/pdf/ibm/24xx/A22-6862-4_2400_Series_Magnetic_Tape_Units_OEM.pdf

that write checking is accomplished by reading. There really isn't anything else you can do when a write fails...
.. well you can retry the write...

> But you get long gaps when you stop/start.

Not on Vacuum Column drives. The columns provide enough mechanical buffering to start and stop within the Inter Record Gap.

>  And a rewrite
> implies that you will get a stop/start situation.
> But in case you already were going stop/start, the gap will not be extended
> any longer.
> 
> You want to stream the tape, meaning you both get short gaps, and also
> much higher transfer rates, as the stop/start really cause the tape to be slow.
> But for streaming mode to work, you need to feed data to the tape fast
> enough. And with that, I mean that when one block operation is finished, the
> command for the next one needs to happen very quickly, or else the tape
> will need to stop.
> 
> This also means that you do not always have a short gap with an error free
> tape. The gap size depends on whether the tape was running at speed or
> not, when the write starts.
> 
> > 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
> > interface.
> 
> Yes. Just as systems expects a block level interface to disks.
> The "stream of bytes" concept is in many cases an artificial construct handled
> by the OS (Unix), and not the hardware.
> 
> 	Johnny
> 
> >
> > Dave
> >
> >> -----Original Message-----
> >> From: cctalk [mailto:cctalk-bounces at classiccmp.org] 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
> > 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.
> >>
> >> 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 nf6x.net>
> >> http://www.nf6x.net/
> >
> >
> 
> 
> --
> 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