Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Dec 1997 08:08:16 -0800 (PST)
From:      dan@math.berkeley.edu (Dan Strick)
To:        gibbs@narnia.plutotech.com
Cc:        dan@math.berkeley.edu, scsi@freebsd.org
Subject:   Re: Questions about mt and SCSI subsystem
Message-ID:  <199712111608.IAA19183@math.berkeley.edu>

next in thread | raw e-mail | index | archive | help
> > My personal policy (in writing tape drivers) is that all drivers for
> > tapes that are capable of overwriting 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?

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?

Yes.  Programs that read tapes should know as little as possible about
specific kinds of tape drives.  In particular, they should not have to
know SCSI error codes.  Note that not all SCSI tape drives support any
sort of end-of-recording recognition.  Some just return a data error.

> > The convention that a raw tape driver return a single zero length

I should have been more explicit.  A tape driver should return a
single zero-length-read to indicate EOF.  The next read should return 
the first record of the next file on the tape (or nothing for another
EOF).  Some modern tape drivers will stop at EOF and return zero length
reads until you close and reopen the device.  This is wrong.  I suspect
that someone wrote a driver that did it wrong (either due to ignorance
or because doing it right is more difficult in fixed-length block mode)
and then the OS vendor "fixed" the problem by declaring this behavior
to be a feature.

I don't know what the FreeBSD SCSI system does.  It might well do this
correctly.  This tirade is really about SCSI drivers in general and not
about the FreeBSD's SCSI driver.

Dan Strick
dan@math.berkeley.edu



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712111608.IAA19183>