From owner-freebsd-scsi Thu Dec 11 11:02:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05524 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 11:02:08 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05515 for ; Thu, 11 Dec 1997 11:02:04 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id MAA00518; Thu, 11 Dec 1997 12:00:02 -0700 (MST) Date: Thu, 11 Dec 1997 12:00:02 -0700 (MST) Message-Id: <199712111900.MAA00518@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 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> In-Reply-To: <19971211101003.17782@uriah.heep.sax.de> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Re: Questions about mt and SCSI subsystem X-Original-Newsgroups: pluto.freebsd.scsi To: Joerg Wunsch cc: scsi@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <19971211101003.17782@uriah.heep.sax.de>, J Wunsch 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 ===========================================