On Mon, 13 Jul 1998, Stefan Grefen wrote:

> > 	1. You "lose" the last write (at least to the writer). When
> > 	you later actually read the tape, the last write you made
> > 	is there- usually all of it (because this is almost always
> > 	a "logical" EOM- usually several megabytes if not tens of
> > 	megabytes before hard EOT), but conceivably just a partial
> > 	write.
> 
> Thats the behaviour you can expect on any UNIX.

Huh? Not on SunOS/Solaris.


> > 	2. The driver doesn't really note that it's at EOM (well, it
> > 	does for fixed block sizes, but not for variable). This allows
> 
> This masut be fixed
>

Yes.

>..
> > user applications counting files will get screwed because they
> > weren't expecting an extra empty file. 
> 
> Thats wrong, 2 FM is EOD (End of Data) and has nothing todo with EOT
> handling.

Well- no, EOD is EOD. 2 Filemarks is a "convention" to note EOD that may
or may not actually work in h/w. But this is not that big of an issue
for me.

>..
> > tape is closed, all further writes return residual==count. A rewind
> 
> The problem is with applications that expect the write to return an error on
> failure (eg. -1) and don't check for residual==count. They may loose
> data on the last record before EOT.
> If we don't use seperate devices for the enhanced features we should return 
> an error for the record after the EAW or the record causing the EAW
> if  residual != 0).
> Then an ioctl can return the residual aqnd enable writing after EOT.
> (I would prefer tradionial and extended device - nodes).

Okay- I see what you're saying. You expanded this below.

> NO NO NO. Only a close causes automagic filemarks. If the application
> wants them it can write them. 

I don't agree- you should never leave a tape unterminated, but perhaps
this is under the aegis of "If the user wants it...so be it"..

> ..
> If you allow writing past logical EOT for 'normal' application data, you
> can't write trailers anymore, as the apllication will have used up all the
> physical tape. So the above should apply to extended feature aware aplications
> only.
> ..
> I second that, (but  I think at least CRAY has and Convex had a tapesubsytem
> able to handle multi-volume and labeled tapes).
> 
> I would add st.c est.c for the new tapesystem and depending on dev-node use
> either the code in st.c or est.c to handle a tape. That avoids most of the
> compatibility problems.
> ...
> 
> Thats why I think we should keep the 'standard' (suboptimal) UNIX 
> tape-basics, so that simple programs using the tape don't havee to 
> add a #ifdef NetBSD ....
> 
> ...
> If things like  multi-volume and labeld tapes are to be added sometime
> I think a redesign of the tapesystem is needed, reagdless of CAM or
> the current scsi-layer  ...
> ...
> I would at least make it a compile timeoption (off by default), 
> I would expect (without analyzing) it to break several applications ...

So, your basic idea here is to do some fixups and extensions
but not to change the basic behaviour and have an 'extended
behaviour' st node and/or compile time options.