Date: Thu, 11 Dec 1997 12:00:02 -0700 (MST) From: gibbs@narnia.plutotech.com (Justin T. Gibbs) To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: scsi@FreeBSD.org Subject: Re: Questions about mt and SCSI subsystem Message-ID: <199712111900.MAA00518@narnia.plutotech.com> In-Reply-To: <19971211101003.17782@uriah.heep.sax.de> 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> <19971211101003.17782@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <19971211101003.17782@uriah.heep.sax.de>, J Wunsch <j@uriah.heep.sax.de> writes: > 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 shouldn't return ENOSPC? This error code is documented in write.2. I agree that EIO is incorrect. -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712111900.MAA00518>