>
> > This whole thing does make one wonder, however, about how a system
> > like this behaves normally in a crash. We aren't *supposed* to need to 
> > do special stuff in order to assure that stuff like metadata is
> > cleanly out after a sync()....
>
>...well, the file system can't really tell if the device underneath
>is actually putting the bits on the metal.

Yes it can. That's what close should ensure at the very least!
If panics/reboots don't do closes, then maybe they should be fixed.

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