Date: Sun, 12 Apr 1998 01:21:27 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Message-ID: <199804120721.BAA09794@narnia.plutotech.com> In-Reply-To: <199804070732.XAA28712@revolution.3-cities.com> <19980411204617.63713@uriah.heep.sax.de> <19980412105735.37665@freebie.lemis.com> <19980412083937.23967@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <19980412083937.23967@uriah.heep.sax.de> you wrote: > As Greg Lehey wrote: > >> My understanding is that the CAM driver returns ENOSPC. I don't know >> whether it performs a partial write, but as long as it correctly >> reports what it does, that's fine by me. > > I don't care what's fine by you. :) ENOSPC is equally wrong as EIO. ENOSPC is the correct error code. It is even documented in dump that it's lack of handling ENOSPC as EOT is a bug. I have patches that fix this problem. > EOF/EOM _must_ return a partial write, *and no error*. In variable block mode, there is no partial write performed by the device, so ENOSPC is returned immediately at EOM. In fixed block mode, if some blocks were written, a short write is returned with no error, but the next write attempt will return ENOSPC. EOF will return either a partial read, followed by a 0 length read, or a 0 length read if you just happen to be at EOF when a read is attempted. We follow the SCSI tape semantics whereby the logical head position is after the filemark after a filemark is encountered. This means that the first read after a filemark, starts into the next file. EOM returns a 0 length read. > 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. > Since tapes cannot seek (at least > not in the current driver, although it's probably possible for some > drives to teach them seeking), the question is not so easy to answer > when you really have to return an error. I think the following would > be OK for all the existing software: > > . write(2) starts before EOM, but the requests spans EOM: the syscall > writes as much as can be handled, and returns a short write (but no > error). > > . first write(2) request that starts exactly at EOM: special case of > the above, the syscall returns just 0, but no error. > > . repeated attempt of the previous case: return EINVAL. Why is EINVAL a more appropriate error code than ENOSPC? > 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. You either have to return no error, or return the correct error. ENOSPC makes perfect sense and we should use it. -- Justin 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?199804120721.BAA09794>