From owner-freebsd-scsi Thu Dec 11 08:08:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22618 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 08:08:25 -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 IAA22607 for ; Thu, 11 Dec 1997 08:08:22 -0800 (PST) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id IAA19183; Thu, 11 Dec 1997 08:08:16 -0800 (PST) Date: Thu, 11 Dec 1997 08:08:16 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199712111608.IAA19183@math.berkeley.edu> To: gibbs@narnia.plutotech.com Subject: Re: Questions about mt and SCSI subsystem Cc: dan@math.berkeley.edu, scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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