[Info-vax] Getting tape drive errors make no sense

[Johnny Billquist]

On 2013-10-31 22:22, glen herrmannsfeldt wrote:
> George Cornelius <cornelius at encompasserve.org> wrote:
>
> (snip)
>>> I am not sure what you mean, but I have seen SCSI tape drives
>>> reblock data. They can be set to always write with a fixed block
>>> size like 1K, or they can be set to write each block to the
>>> appropriate size, sometimes called variable length.
>
>>> If it is set different than you expect, the results can be
>>> surprising.
>
>> He was probably referring to the 32767 byte limit on RMS
>> record size, something that interferes with copying, say,
>> a tape with blocksize 65024 to an RMS file.  And, of
>> course, the other drawback of copying to an RMS file:
>> that VMS BACKUP's bad block handling is not understood
>> by a COPY command, so there will be no attempt to
>> deal with bad blocks which were successfully rewritten
>> on a second or later attempt (hint: for reliability
>> reasons, BACKUP does _not_ backspace and overwrite - at
>> least as long as the /INTERCHANGE qualifier is not
>> present).
>
>> With regard to reblocking by SCSI drives, it can be done
>> in a transparent way - I believe DLT's do this - so that
>> the O/S does not have to know it is happening; but if there
>> are drives or controllers that do this in a nontransparent
>> way, that mode of operation is not compatible with VMS.
>
> The unix write() system call writes one block of the
> specified length. The read() system call reads one block
> or the specified length, whichever comes first.

Depends... On a block device, it writes that many bytes. It might become 
one block, or many... Or just a part of a block...

>> I believe Unix/Linux may try to make tapes appear to
>> be byte stream oriented, this being a somewhat different
>> concept from so-called streaming hardware.  But under
>> Unix the programming interface may be hiding the detailed
>> information about the blocking through its use of buffers.
>> My experience is that tar is quite unhappy if the block
>> size is different from the default and you do not
>> specify, or incorrectly specify, the blocksize via
>> the command line.
>
> If the program expects a byte stream, then it will get one,
> reading however many bytes are available. If the program expects
> tape blocks, then it gets confused it it is reblocked.
>
> I don't remember exactly how I found this, but it was on a
> LTO drive I bought cheap on eBay. There is an mt (unix command)
> to change the block size on SCSI drives.

These are also two different issues. Tape drives which hide blocking, 
and present some weird non-tape interface over SCSI are totally 
unfamiliar to me, but if they exist, I guess anything goes.

Programs in Unix, that use tapes, can go through either the block 
device, or the raw device. The block device gives you a stream of bytes. 
Pretty much the same as when you access disk files. Even though a disk 
consists of 512 byte blocks, you actually get just as much as you asked 
for, and the next read will continue right where the previous stopped. 
The OS keeps the block in a buffer for your operations.

The raw device skips all that stuff, and just gives you what the actual 
device had. Any excessive data not fitting in your read is just lost. If 
you try to read too much, you get an error indicating that the record 
was shorter, you get the actual numbers read, and all the data there was.

The block device for tapes under Unix always use 512 byte tape records, 
just so you know...

	Johnny