[ On Tue, December 12, 1995 at 02:54:55 (-0800), Erik E. Fair wrote: ]
> Subject: Re: Tapeboot problem SOLUTION
>
> Is QIC really defined that way in the standard? In most older UNIX tape
> systems that I've seen, if you use the character special device, you can
> write a record of any size within the minima and maxima of the medium (i.e.
> within what the driver and the device will allow - with the exception of
> never-sufficiently-damned System V UNIXes, of course).

I don't think that the QIC standard has anything to say with how a UNIX
driver should treat I/Os to the raw device.  Indeed many UNIX
implementations do as you say by buffering and/or padding smaller
writes.  I must admit I was highly purturbed when I had a dd to a tape
fail for the first time on an AIX 3.2 box.  It was at first very
annoying since I thought I knew that dd did everything on block
boundaries and here was the driver claiming there was an incomplete
block written.

As it turns out the QIC standard does define the format of the tape
itself to be invariably 512-byte blocks and from what I could find out
there were some statements that device operations were mandated to
always be in units of 512-byte blocks.  I believe all QIC tape devices
carry this mandate all the way to their embedded SCSI interfaces.

In the end I have come to despise QIC tape drivers that do not enforce
this modulo-512 byte limit, since the drivers which do enforce this
limit are the only ones that guarantee I can always read back the exact
same data as it was written to the tape and may also do so on any other
similar tape device.

I'm curious how the NetBSD drivers handle this.  I've only once tried to
use a tape on a NetBSD system [SPARC-1.0A (~Nov 94?)] and that one often
crashed the system with even an 'mt rewind'.  It seems to work OK for
1.1 on Sun3, but I've yet to explore for sharp edges and dark corners.

> With 9-track tapes,
> the range was pretty wide (1 byte to 10's of K). It has always been the
> block special devices that enforce some device specific block size (usually
> 512 bytes) or multiples thereof.

Ah, yes, as you say the 9-track tape drive is a wonderfully flexible
device and it gives a great deal of freedom to the OS implementor, even
with well done embedded SCSI implementations.....

> The trouble with speaking to a tape drive through the SCSI bus is that
> unless the driver is aware of which tape standard a given drive is speaking
> (e.g. 9-track, QIC, DAT, DLT, 8mm Helical Scan (Exabyte), IBM 3840, just to
> name a few), how can it reasonably enforce a block size?

Hmm....  Well, that's easy.  There's a SCSI "MODE SENSE" command that
the driver must send to any sequential access device to discover the
block descriptor (if any).  If the block length field is zero, then the
block size is variable and the logical block size written to the medium
is specified by the transfer length field in the command descriptor
block I believe the driver may set the current block size using a "MODE
SELECT" command.  A non-zero block length indicates a fixed length block
size supported by the device.  Of course you discover if the device is
sequential access by doing a normal "INQUIRY" command, and if the
"Peripheral device type" is 0x01, then you're talkin' to a sequential-
access device such as a tape.  So far as I know all of this stuff was
supported back to SCSI-1 too (it's in my copy of the AT&T "SCSI
Definition, Issue 2" which describes AT&T's implementation of ANSI
X3.131-1986).

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>