Date: Wed, 10 Dec 1997 01:23:59 -0700 (MST) From: gibbs@narnia.plutotech.com (Justin T. Gibbs) To: dan@math.berkeley.edu (Dan Strick) Cc: scsi@FreeBSD.org Subject: Re: Questions about mt and SCSI subsystem Message-ID: <199712100823.BAA19029@narnia.plutotech.com> In-Reply-To: <199712100705.XAA22478@math.berkeley.edu> References: <199712100705.XAA22478@math.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199712100705.XAA22478@math.berkeley.edu>,
dan@math.berkeley.edu (Dan Strick) writes:
>> 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.
This doesn't quite jibe with either the SCSI II or SCSI III spec.
Essentially they define three different terms:
EOD - End of data in a partition is denoted in a format-specific manner.
EOM - The extreme position along the medium in the direction away from the
take-up reel which can be accessd by the device. This position may
be accessed by devices that support the LOAD UNLOAD command with the
EOT bit set to one.
EOP - The position at the end of the permissible recording region of a
partition.
In respects to a read, you can be notified for:
1) A filemark being read.
2) A setmark being read.
3) hitting early warning.
4) hitting EOD (if the drive supports recognizing EOD).
5) hitting EOP
Both EOD and EOP set the logical "EOM" flag in the status you get returned.
> 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.
Backspace a single filemark, correct?
> 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).
You favor this even if the media is specified to have a different EOD
convention... perhaps even one that the drive writes on your behalf?
> 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 shouldn't have included filemarks in my statement. This behavior is
aintained in both versions of the driver.
> 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.
I'm all for doing it right so long as I can read tapes that were written
using a different vendor's OS and they can read my tapes too.
> Dan Strick
> dan@math.berkeley.edu
--
Justin T. Gibbs
===========================================
FreeBSD - Turning PCs into workstations
===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712100823.BAA19029>