JLS2009: A Btrfs update
Posted Nov 1, 2009 21:37 UTC (Sun) by anton
In reply to: JLS2009: A Btrfs update
Parent article: JLS2009: A Btrfs update
In a good file system, the state after recovery is the logical state
of the file system of some point in time (typically a few seconds)
before the crash. It's possible to implement that efficiently
(especially in a copy-on-write file system).
For an editor that does not fsync(), that would mean that you lose
a few seconds of work (at worst the few seconds between autosaves plus
the few seconds that the file system delays writing).
For every application (including editors), it would mean that if
the developers ensure the consistency of the persistent data in case
of a process kill, they will also have ensured it in case of a system
crash or power outage. So they do not have to do extra work on
consistency against crashes, which would also be extremely impractical
It should not be too hard to turn Btrfs into a good file system.
Unfortunately, the Linux file systems seem to regress into the dark
ages (well, the 1980s) when it comes to data consistency (e.g., in the
defaults for ext3). And some things I have read from Chris Mason lead
me to believe that Btrfs will be no better.
As for the guarantees that fsync() gives, it gives no useful
guarantee. It's just a prayer to the file system, and most file
systems actually listen to this prayer in more or less the way you
expect; but some require more prayers than others, and some ignore the
prayer. I wonder why Ted T'so does not apologize for implementing
fsync() in a somewhat useful way instead of the fastest way that still
satisfies the letter of the POSIX specification.
to post comments)