Date: Wed, 23 Dec 1998 02:12:13 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) To: freebsd-scsi@FreeBSD.ORG Cc: dan@math.berkeley.edu Subject: /dev/nrsa0 file mark handling Message-ID: <199812231012.CAA17288@math.berkeley.edu>
next in thread | raw e-mail | index | archive | help
I came across the following text near the end of the "sa" man page
on one of my release 3.0+ systems:
The handling of file marks on write is automatic. If the user has written
to the tape, and has not done a read since the last write, then a file
mark will be written to the tape when the device is closed. If a rewind
is requested after a write, then the driver assumes that the last file on
the tape has been written, and ensures that there are two file marks
written to the tape. The exception to this is that there seems to be a
standard (which we follow, but don't understand why) that certain types
of tape do not actually write two file marks to tape, but when read, re-
port a `phantom' file mark when the last file is read. These devices in-
clude the QIC family of devices. (It might be that this set of devices
is the same set as that of fixed block devices. This has not been deter-
mined yet, and they are treated as separate behaviors by the driver at
this time.)
I could have sworn that the automatic EOF mark issue was discussed within
the last year on one or more of the freebsd mailing lists. Traditional
behavior of traditional tape systems (i.e. 7 or 9 track open reel drives
dating back at least 25 years) was to write one tape mark after each
file (hence the name "EOF mark") and to write an extra tape mark after
the last file to indicate the end of the recorded portion of the tape.
This was an absolutely wonderful convention. It made all sorts of useful
tape management procedures (e.g. recording checking and tape copying)
independent of the data on a tape or the way in which it was formatted.
The way to ensure the existence of the "extra" tape mark was to write
two EOF marks after each file and backspace over the second mark.
This convention was widely followed until the introduction of those
junky QIC drives that used serpentine recording with a full tape width
erase head separate from the recording head. The erase head is turned
on while writing the first track. If you think about it, it should be
pretty obvious that such a tape drive cannot safely write except at
BOT (beginning of tape) or at EOM (end of recorded medium). QIC tape
driver writers coped as best they could. They stopped writing double
EOF marks and fudged the "phantom" EOF mark for the benefit of
programs that expected the old EOM convention.
(Note: traditional 9 track open reel tape drives cannot detect EOM.
Modern SCSI drives generally can detect EOM and most will refuse to
advance the tape past EOM. I believe this is sometimes foolish "user
friendly" behavior designed to prevent fools from shooting holes in
their feet.)
I basically like the automatic file mark behavior claimed for the "sa"
device except that the driver should contain a short list of popular
tape drives that are known to be capable of writing over file marks
(there ought to be a mode page field that indicates this) and do the
double-EOF + BSF procedure at the end of every new file on those drives.
While I am at it, I have another "request". The "sa" tape driver
still needs a "control" device or some other way of accessing the
driver without conflicting with current I/O activity in order to
discover device status via the MTIOCGET ioctl(). (An alternative to
a control device would be special interpretation of the O_NONBLOCK
open flag.) It would be nice if the "struct mtget" fields mt_fileno
and mt_blkno were implemented. It would be nice if there was another
field that indicated the nature of any tape operation in progress
(e.g. REW, FSF, WEOF, simple I/O).
So much for dreaming. I have to get "back to work". I would be
curious as to which of these suggested features people would actually
like.
Dan Strick
dan@math.berkeley.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812231012.CAA17288>