From owner-freebsd-scsi  Tue Dec  9 23:05:43 1997
Return-Path: <owner-freebsd-scsi>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA22847
          for freebsd-scsi-outgoing; Tue, 9 Dec 1997 23:05:43 -0800 (PST)
          (envelope-from owner-freebsd-scsi)
Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22841
          for <scsi@FreeBSD.ORG>; Tue, 9 Dec 1997 23:05:39 -0800 (PST)
          (envelope-from dan@math.berkeley.edu)
Received: (from dan@localhost)
	by math.berkeley.edu (8.8.7/8.8.7) id XAA22478;
	Tue, 9 Dec 1997 23:05:33 -0800 (PST)
Date: Tue, 9 Dec 1997 23:05:33 -0800 (PST)
From: dan@math.berkeley.edu (Dan Strick)
Message-Id: <199712100705.XAA22478@math.berkeley.edu>
To: scsi@FreeBSD.ORG
Subject: Re: Questions about mt and SCSI subsystem
Cc: dan@math.berkeley.edu
Sender: owner-freebsd-scsi@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> In SCSI, there is no such thing as an "EOT" marker.  Instead, you must

Modern SCSI tape systems typically recognize some combination of
physical EOT (beyond which you cannot write), logical EOT (beyond
which you might be able to write if you know the magic commands),
and EOM (after the most recently written record on a sequential
access tape).  The details depend mainly on the exact medium and
somewhat on the drive.  I don't remember how much of this is
standardized in the various versions of SCSI.

> The Berkeley convention was that 2 filemarks in a row signaled EOT.

This convention (which as far as I know did not originate at UCB)
predates all flavors of Unix.  It was a really simple and convenient
device and OS independent convention for marking the end of data.
It did have the disadvantage that it discouraged empty files and
it was finally broken by modern cheap tape drives that were not able
to overwrite EOF marks.

My personal policy (in writing tape drivers) is that all drivers for
tapes that are capable of overwritting EOF marks should write a double
EOF and then backspace before closing the device or doing any tape motion
operation if the previous tape operation was a write.  For drives
that are not capable of overwriting EOF marks, I favor the convention
that a single EOF mark (with no backspace) be written in these
circumstances and that a double EOF mark be written before rewinds
(even though this may inconvenience lazy programmers who don't think
ahead).

Of course, nobody ever listens to me ... :-)

> Right now, we only have a single error code to pass back to the application
> for filemarks, setmarks, EOD, and EOM.  Either we have to add some error
> codes or add an MT ioctl so the application can determin what the exact
> cause of the EIO was.

The convention that a raw tape driver return a single zero length
read to mark EOF is very ancient and should be respected because it
is so darn useful.  It means that a program can distinguish between
a read error and an end of file without knowing specific error codes.
I would rather not see that convention change just because some
tape drivers were written by people who were too green to know the
convention or were unable to appreciate its value.

I think we should strive to do the "right" thing even though major
OS vendors do it wrong.

Dan Strick
dan@math.berkeley.edu