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....)...