Subject: (2nd send) opinion sought about EOM handling for tapes
To: None <tech-kern@NetBSD.ORG>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 07/09/1998 18:50:44
[ I sent this ought last week but didn't hear any opinions about
this. Yet another bug at NASA/Ames related to EOM handling showed
up again- so I'd really like to fix it. I can do *some* fixing
without making the following change, but while I'm at it, I
thought it would be worth doing.
Please respond one way or the other about this if you care ]
Currently while writing if you hit EOM, that returns an EIO
and complains loudly.
I'd like to change this to (and yes, this is swiped from a
well known commercial OS, but the behaviour appeals to me. Well,
it would....:-)):
When logical EOT is encountered during a write, that write
operation completes and the number of bytes successfully
transferred is returned (note that a 'short write' may have
occurred and not all the requested bytes would have been
transferred. The actual amount of data written will depend
on the type of device being used). The next write will
return a zero byte count. A third write will successfully
transfer some bytes (as indicated by the returned byte
count, which again could be a short write); the fourth will
transfer zero bytes, and so on, until the physical EOT is
reached and all writes will fail with EIO.
Until the EIO, no complaints to the console are necessary, or
wanted (unless SCSIDEBUG is set). This allows trailing records
to be written with some kind of warning the application that
life is getting dangerous. The only risk factors here are for
tape devices that cannot note hard physical EOT. This should
only in fact be 1/2" reel tape, and, err, umm, just *how many*
of these beasts are out there on SCSI busses at this point
(a flood of email comes in....)...