From owner-freebsd-scsi Thu Dec 11 15:52:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25597 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 15:52:51 -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 PAA25591 for ; Thu, 11 Dec 1997 15:52:47 -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 AAA01956 for scsi@freebsd.org; Fri, 12 Dec 1997 00:52:41 +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 AAA13599; Fri, 12 Dec 1997 00:46:51 +0100 (MET) Message-ID: <19971212004650.09374@uriah.heep.sax.de> Date: Fri, 12 Dec 1997 00:46:50 +0100 From: J Wunsch To: scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712111641.IAA20249@math.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712111641.IAA20249@math.berkeley.edu>; from Dan Strick on Thu, Dec 11, 1997 at 08:41:03AM -0800 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 Dan Strick wrote: > In my opinion, short writes should not be allowed. The driver should > return an error in such circumstances. So how are you going to find out how much actual space there still has been in this case? Don't think of variable-length recording tapes in the first place, and assume the caller wanted to write 10 KB (aka. 20 blocks 512 bytes each). There were only 8 blocks free on the tape. How do you express this if you reject the complete write call, as opposed to writing 4 KB worth of data, and returning this to the caller? Btw., even if you want, you IMHO can't. You write them block by block to the tape, and get the EOM notification of the drive only after having written 4 KB of data. So, the data are actually there on the medium already, pretending to the caller they weren't would confuse the heck out of the volume-span logic of the corresponding program, when trying to read across the end of this volume. The only solution seems to be a `short write'. -- 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. ;-)