From owner-freebsd-scsi Wed Dec 10 00:52:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29362 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 00:52:12 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA29355 for ; Wed, 10 Dec 1997 00:52:08 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA05764 for scsi@FreeBSD.ORG; Wed, 10 Dec 1997 09:52:06 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id JAA07713; Wed, 10 Dec 1997 09:37:32 +0100 (MET) Message-ID: <19971210093732.48185@uriah.heep.sax.de> Date: Wed, 10 Dec 1997 09:37:32 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712100243.TAA18226@narnia.plutotech.com>; from Justin T. Gibbs on Tue, Dec 09, 1997 at 07:43:28PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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. ;-)