Date: Thu, 11 Dec 1997 10:10:03 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Message-ID: <19971211101003.17782@uriah.heep.sax.de> In-Reply-To: <199712110327.UAA17646@narnia.plutotech.com>; from Justin T. Gibbs on Wed, Dec 10, 1997 at 08:27:55PM -0700 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971211101003.17782>