Messages in this thread | | | Date | Tue, 26 Feb 2008 17:00:11 +0000 | From | Jamie Lokier <> | Subject | Re: Proposal for "proper" durable fsync() and fdatasync() |
| |
Jeff Garzik wrote: > Nick Piggin wrote: > >Anyway, the idea of making fsync/fdatasync etc. safe by default is > >a good idea IMO, and is a bad bug that we don't do that :( > > Agreed... it's also disappointing that [unless I'm mistaken] you have > to hack each filesystem to support barriers. > > It seems far easier to make sync_blkdev() Do The Right Thing, and > magically make all filesystems data-safe.
Well, you need ordered metadata writes, barriers _and_ flushes with some filesystems.
Merely writing all the data pages than issuing a drive cache flush won't Do The Right Thing with those filesystems - someone already mentioned Btrfs, where it won't.
But I agree that your suggestion would make a superb default, for filesystems which don't provide their own function.
It's not optimal even then.
Devices: On a software RAID, you ideally don't want to issue flushes to all drives if your database did a 1 block commit entry. (But they probably use O_DIRECT anyway, changing the rules again). But all that can be optimised in generic VFS code eventually. It doesn't need filesystem assistance in most cases.
Apps: don't always want a full flush; sometimes a barrier would do.
-- Jamie
| |