> From: Matthew Jacob <mjacob@feral.com>
>
> [ 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....)...

Well, someone should respond to this, so I will try.


1. I think you might be on the right track here, and I'm glad you are
putting effort into it, but I've reread your message several times and I
can't quite tell:

	A. What is the problem you are trying to solve?

	B. What is the point of the change?

	C. Did they do this just so they could write those stupid little
	ANSI 80-byte bracket records?  I haven't seen an ANSI format tape in
	almost a decade. Does it even work on fixed-block tapes?

2. I don't think you should break 9-track handling.

	A. It should be easier to deal with, not harder, since as you
	probably know, 9-tracks do detect EOM, and in addition they allow
	writing a certain distance _past_ it, so you actually get to
	correctly finish the tape record that hit the EOM, and then write
	small records past that if you must. It's just a warning on 9-tracks.
	(It seems safer to back up and rewrite the record on the next volume,
	though. See 3A/3B.)

	B. If it takes a little complexity to _not_ remove existing
	functionality, then fine, that's acceptable complexity.

3. Incremental bug fixes and development are just fine, but since you are
making an _interface_ change (right?) I think you need to put the effort
into finalizing the interface rather than stepping it.

	A. If you are going to deal with EOM, you also might want to deal
	with EOV and with multi-volume tape files. This is something Unix
	hasn't ever really done...the uniquely unix way of telling dump
	how big the tape is was never needed on other (non-M$) systems.
	If it's hard to do this in a compatible way, then you can
	always slice a bit off the minor number to specify the new model.

	B. On other systems, you can write as much stuff as you want and
	it just _works_. Tape volumes are changed at a layer below the
	application. The applications usually had knowledge of this so they
	weren't forced to read from tape 0; I don't know if writing
	multi-volume tape files was completely transparent or not, but it
	was certainly _possible_. We don't do that at all on Unix...the
	multi-volume dump(8) tapes are just application-layer-concatenated
	multiple single-file volumes, and not a multiple-volume file. Quite
	crude, really. But it's a cool feature and to do EOM "right" this
	is what you need.