Date: Wed, 10 Dec 1997 09:37:32 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Message-ID: <19971210093732.48185@uriah.heep.sax.de> In-Reply-To: <199712100243.TAA18226@narnia.plutotech.com>; from Justin T. Gibbs on Tue, Dec 09, 1997 at 07:43:28PM -0700 References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Justin T. Gibbs wrote: > The FreeBSD st driver (including the CAM one), > return EIO when a filemark is encountered or a "blank check" is reported. > It's up to the reading program to decide what that means. This is wrong. It breaks the normal conventions for read(2) that say encountering EOF upon a read request should terminate the request with an appropriate return value (possibly 0 bytes read), but with no error condition. As such, it breaks the EOF detection in dump(8). Of course, returning EIO afterwards is appropriate. > Assuming the device supports the READ POSITION scsi command, there's no > reason we can't add this feature to mt/sa(4). Unfortunately, READ POSITION only reports block numbers, but not tape file numbers. A block number is rather useless for most people, while many are interested in the current tape file number. We have to count the filemarks manually in the driver, i'm afraid. (I've been playing with READ POSITION a little.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971210093732.48185>