In message <Pine.LNX.3.93.980713052829.16463C-100000@feral-gw>  Matthew Jacob wrote:
> 
> 
> On Mon, 13 Jul 1998, Stefan Grefen wrote:
> 

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

I've seen programs (and wrote one) which uses this 'feature' to do a
bsr/rew before a close to avoid writing the EOD marker. 
rewind-offline should write it of cause.

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

Yes, breaking amanda and other popular tools is nit a godd idea, and very
few people need 'real' tape-systems.
BTW. HPUX uses 4 minor bits or so to differiante between the various 'options'
(bsd or sysv, rew - norew, one or two filmarks as EOD ...).

Stefan
> 
> 

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---