Tape records - test-drb@ccmp.vtda.org

6 Apr 2009

Richard <legalize at xmission.com> wrote:
...
  In article <2877e57dba24bc750739ccec428ded28 at
lunar-tokyo.net>,
     Daniel Seagraves <dseagrav at lunar-tokyo.net>  writes:
   In
article 
 <f4eb766f0904031640g7c90507eo92411f16365021e1 at mail.gmail.com>,
     Ethan Dicks <ethan.dicks at gmail.com>  writes:

> Back in the day, we used to move copies around on magtape, bypassing
> all sorts of stream-of-bytes issues.  Today, of course, most things
> expect streams of bytes, so that's how most things are presented.  On Apr
4, 2009, at 12:53 PM, Richard wrote:

  How does magtape avoid the stream-of-bytes issue?
 Magtape has blocks.  
 What exactly is a block?

 Is it defined as a sequence of bits or as a sequence of bytes?

 If its just a sequence of bytes that define a block, I'm not sure I
 understand how blocks avoid the stream-of-bytes issue. 
Good question. And people have some interesting answers as well. :-)

A tape block is simply a bunch of bytes. The point is that it is a 
spcific number of bytes. A single read or write will process one tape 
block. This is important. It means that doing two consequtive writes for 
n bytes will not produce the same result as one write for 2*n bytes.
It also means that if you request to read n bytes, and the tape block is 
shorter, you will not get data from the next tape block in addition to 
the current, but instead the read will return less data.

Assuming the block is n bytes long, and you request a read for x number 
of bytes.

If x > n you will get the whole block, but no more than the block.
If x < n you will only get x bytes from the block, while the rest will 
be skipped. The next read will read from the next block anyway.

Each block is physically separated from other blocks by a inter-block 
gap. This is meta-data that is not received as a part of a read, but 
which can be inferred from the number of bytes actually read, unless you 
get a data overrun error, in which case the block was larger than the 
read allowed for.

In addition to this, you also have something called file marks. When you 
read and the tape position is at a file mark, you usually get a return 
value indicating that you read 0 bytes. This is a hint that it was a 
file mark you passed.

Convention then have it that two consequtive file marks indicates the 
logical end of tape.

However, ANSI-formatted tapes look and work slightly different, but that 
is all still implemented on top of the concept of tape blocks and file 
marks. Those two details are defined by hardware.

This means that a tape can never properly behave like a stream of bytes. 
As I've said, Unix have a way of trying to make tapes look like a stream 
of bytes, but noone uses that, since it's not useful, nor meaningful.
Even in Unix, you can control these things correctly from a program. 
That's what ioctls are for.

	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