JLS2009: A Btrfs update
Posted Nov 2, 2009 21:58 UTC (Mon) by anton
In reply to: JLS2009: A Btrfs update
Parent article: JLS2009: A Btrfs update
But I don't want fsync() to do nothing at all, because
there are lots of cases where a poorly-timed crash can cause you to
lose not 10 minutes of work, but your entire data store. This applies
to basically anything using a more complex data storage strategy than
"rewrite the entire data store every time", e.g. dbm, sqlite,
If these applications don't corrupt their storage when they crash on
their own or are killed, they won't corrupt it on a good file system
even on a system crash. So it's only on bad file systems where the
absence of fsync() would cause consistency problems. And how can you
be sure that the fsync()s called from these applications are
sufficient? Testing this stuff is pretty hard.
There is a different reason for syncing in such applications: A
remote user won't notice that the database server lost power or
crashed right after his transaction went through, so the database
should better ensure that the data is in permanent storage before
reporting completion to remote users.
As for the firefox history, a good file system would be a way to
avoid losing it completely, without requiring fsync().
to post comments)