> > mechanism for write ordering. Assuming that either write-through
> > caching is used or write-back with the battery backup unit, the
> > controller will guarantee that once the OS has been told the write has
> > completed successfully then the disks will be updated eventually
> > unless enough of a hardware failure occurs.
>
> In that case we'll need a mechanism for detecting the battery backup unit, and
> enabling write-through operation if it's absent. That should suffice.
This should be in userspace, à la hdparm. If the machine has a UPS, the
admin possibly has a clue or two (of course, since he's running Linux in
the first place!), so he'll tweak the machine accordingly, including
setting up a powerd and putting some hdparm in the rc.local file.
> If we could provide the same kind of control on all devices (partial ordering,
> complete cache flush, whatever) then a single strategy could be used to ensure
> consistency on each type of device. Otherwise we might have to implement
> slightly different filesystem routines, depending on the type of device it's
> on. We may well want to do things slightly differently, depending on the
> facilities available from the block device.
There should be just a simple "sync()" function for block devices (if
there isn't already one) implemented, so that you simply sync() the
journal device after writing to it. I think this would be very general
and could be used in other contexts. Other way would having "really raw"
block devices... I think database people are asking for this?
-- Pierre Phaneuf Web: http://newsfeed.sx.nec.com/~ynecpip/ finger: ynecpip@newsfeed.sx.nec.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu