10 Jun
2015
10 Jun
'15
2 a.m.
-----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:
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_Magn…
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...
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. 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
--
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 -----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/