Date: Sun, 12 Apr 1998 12:43:40 +0200 From: J Wunsch <j@uriah.heep.sax.de> To: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Message-ID: <19980412124340.50537@uriah.heep.sax.de> In-Reply-To: <199804120721.BAA09794@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Apr 12, 1998 at 01:21:27AM -0600 References: <199804070732.XAA28712@revolution.3-cities.com> <199804120721.BAA09794@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Justin T. Gibbs wrote: > > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. > > ENOSPC is the correct error code. Where did you get this from? All descriptions for ENOSPC i could find (our own man page, as well as ``The single UNIX specification'' on http://www.rdg.opengroup.org/onlinepubs/ -- i don't have access to the appropriate Posix docs) make it very explicit that ENOSPC is only related to regular files and directories. > It is even documented in dump that > it's lack of handling ENOSPC as EOT is a bug. No. I can't seem to find it. The only mention of ENOSPC is: /* * fixme: Pyramids running OSx return ENOSPC * at EOT on 1/2 inch drives. */ ...which rather sounds like an idiosyncrasy on Pyramid's OS than the admission of a bug in dump. How do you `fix' all the other programs inside and outside our tree? (Start with GNUtar's multi-volume handling for an example.) > > An error must only be returned iff attempting to start the write > > operation beyond the end of medium. > > I don't believe that these are the correct semanics. No error should > be returned if a partial request was satisfied. If the entire request > cannot be satisfied because we are at, or past EOM on a write, an error > should be returned. This is exactly the same semantics as writing to > a file when there is no space left on the device. I think this violates the traditional behaviour. Alas, the existing docs are not fully clear on this, and allow both interpretations. Our own write(2) man page is rather thin on this. The UNXI spec is a little more verbose: If a write() requests that more bytes be written than there is room for (for example, the ulimit or the physical end of a medium), only as many bytes as there is room for will be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a non-zero number of bytes will give a failure return (except as noted below) and the implementation will generate a SIGXFSZ signal for the thread. It only tells about ``the next write of a non-zero number'', and this entire man page doesn't mention special files at all. :( Again, i'm just arguing to follow what's IMHO the traditional behaviour, so software relying on it would work. (And i don't see that this traditional behaviour would be in violent conflict with these specs.) > > . repeated attempt of the previous case: return EINVAL. > > Why is EINVAL a more appropriate error code than ENOSPC? Because ENOSPC is limited by definition. (See above.) > > The latter would help programs that attempt to repeatedly to operate > > beyond the EOM to detect their error, albeit these programs are > > arguably broken. > > The latter would break dump. It waits for write to return 0 10 times > before believing it has hit EOM. OK, i take this one back. -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980412124340.50537>