Date: Sun, 12 Apr 1998 08:39:37 +0200 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI EOT fixed J"org? Message-ID: <19980412083937.23967@uriah.heep.sax.de> In-Reply-To: <19980412105735.37665@freebie.lemis.com>; from Greg Lehey on Sun, Apr 12, 1998 at 10:57:35AM %2B0930 References: <199804070732.XAA28712@revolution.3-cities.com> <19980411204617.63713@uriah.heep.sax.de> <19980412105735.37665@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. EOF/EOM _must_ return a partial write, *and no error*. Anything else breaks the Unix semantics, and thus all programs that rely on Unix semantics (dump(8), multi-volume tar(1)). An error must only be returned iff attempting to start the write operation beyond the end of medium. 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. The latter would help programs that attempt to repeatedly to operate beyond the EOM to detect their error, albeit these programs are arguably broken. For read(2) syscalls, things similarly apply to each single tape file, but IMHO there's no EOM detection required, only detection of EOF on each tape file. A repeated attempt to read beyond the EOF of one tape file should however advance to the next tape file if possible, and only yield an error iff no more tape files are available. I think tape driver semantics slightly differ in this behaviour across the various Unix systems. :( -- 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?19980412083937.23967>