which is an unfortunate way to have to go because you lose a lot of write
performance by turning off write caching.

flushing is one way to get your data in sync.  Another is to set the Force
Unit Access bit in the scsi command to get write-through caching rather than
write back.  Of course that requires crawling through the file systems and
deciding which i/o's have to be on the disk immediately (metadata) and which
can go on the disk later (user data depending on what the client wants) and
requires a way for the fs to communicate this need to the disk drivers on an
i/o by i/o basis.

FUA combined with flushing can probably get a reasonable mix of caching and
data integrity.  

Of course database people will want a way to turn off the write caching of
user data as well (though they could send their own flushes).  And you still
have to deal with drives that have bad write-back cache implementations
(though i think that manufacturer has finally started fixing their problems)
and drive vendors who decided to ignore the FUA bit because some operating
systems use it extensively (excessively?) and it screws up their performance
scores in the trade rags.  And IDE drives where flushing the cache can get
you behavior somewhere between nothing and flushing the dirty data (with
interesting mid points like drives that also park their heads when you flush
them).

All in all, IMHO turning it off write caching is the safest path.  But
you'll really miss being able to stream data to your drive at media speed if
you do.

-p

-----Original Message-----
From: Matthew Jacob [mailto:mjacob@feral.com]
Sent: Thursday, June 11, 1998 10:25 AM
To: thorpej@nas.nasa.gov
Cc: tech-kern@netbsd.org
Subject: Re: test of new powerdown facility


...

I'm still very uneasy about this SYNCHRONIZE CACHE thingie. If this
drive has writeback cacheing enabled by default, you're no better
off (as I've said) than having a filesystem where all I/O is
async.

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