As Chris G. Demetriou wrote...
> > >I like Chris's idea of a generic "make sure the data is sync'd" ioctl
> > >that the buffer cache and/or file system code can use.
> > 
> > No, that's really not the right thing to do I believe, *unless* you
> > go to the effort of an ioctl that also *enables* device cacheing.
> > I believe that block devices should not have this cache enabled 
> > unless requested (and this should be enforced in the driver).
> 
> I agree.  However, I don't know enough about the cache operations on
> SCSI and other drives to know if that's easily possible to accomplish
> on all (or the vast majority of) drives.  You and others are much more
> qualified in that regard.  8-) (It's worth noting that there are other
> implications of not forcing sync writes through to the disk.
> E.g. what does fsync() really force?)
> 
> Even running async with caches enabled, i'd _still_ expect 'sync' to
> flush the written bits all the way to the platter.  If that property

You should be able to send SCSI WRITE commands with the immediate bit
(I think it's called) set. This should force a write all the way to the
platter and only then reporting I/O complete back to the host.

You need the SCSI specs to get the details on this.

> can be obtained by forcing synchronous writes to hit the disk, great.
> That'll solve the problem.  However, if that's not possible, some
> explicit, device-specific 'sync' operation (e.g. an internal-use
> IOCTL) might be necessary.

Yuck..


Wilko
_     ______________________________________________________________________
 |   / o / /  _  Bulte 				  email: wilko @ yedi.iaf.nl 
 |/|/ / / /( (_) Arnhem, The Netherlands          WWW:   http://www.tcja.nl
______________________________________________ Powered by FreeBSD __________