> -----Original Message----- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Johnny > Billquist > Sent: 10 June 2015 09:39 > To: cctalk@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-boun...@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 <n...@nf6x.net> > >> http://www.nf6x.net/ > > > > > > > -- > 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
