From owner-freebsd-scsi Thu Dec 11 01:15:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22366 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 01:15:00 -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 BAA22355 for ; Thu, 11 Dec 1997 01:14:57 -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 KAA19627 for scsi@FreeBSD.ORG; Thu, 11 Dec 1997 10:14:36 +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 KAA12050; Thu, 11 Dec 1997 10:10:03 +0100 (MET) Message-ID: <19971211101003.17782@uriah.heep.sax.de> Date: Thu, 11 Dec 1997 10:10:03 +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> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> <19971211005904.40551@uriah.heep.sax.de> <199712110327.UAA17646@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712110327.UAA17646@narnia.plutotech.com>; from Justin T. Gibbs on Wed, Dec 10, 1997 at 08:27:55PM -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 correct behaviour is that any read or write attempt, upon > > encountering EOF (read) or EOM (write) should return a `short' > > read/write (i.e., set b_resid accordingly), but shall not flag an > > error condition. > > Are you sure about the behavior for write? Yep. dump and multivolume tar rely on this behaviour, that's why dump -a is currently broken. (*) It gets an EIO at the end of the tape, and assumes something went wrong with writing the last block, so instead of asking for the next tape (which it would have done upon write() returning 0), it asks to replace the same tape again, and wants to write this one once more. Note that, while dump -a is my invention, the algorithm to detect the end of tape has been there all the time; dump -a only enforces the use of this algorithm over some tape length calculations. (*) It was broken for (almost?) all disk and tape devices in FreeBSD. People have been complaining about not being able to write multivolume floppy tar archives, that finally made me fixing the floppy driver. I'm not sure about sd(4) (and all the derived drivers), whether they do it right or not. -- 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. ;-)