btrfs fscked up, too?
Posted Mar 16, 2009 9:42 UTC (Mon) by forthy
Parent article: Garrett: ext4, application expectations and power management
I'm confused. btrfs is advertized as sort-of log structured,
data&metadata COW file system. How on earth can it have the same
Either Chris Mason does not understand what a log structured file system
is, or he has been infected by the bonehead synchronous metadata idea
that exists in Unix file system developers brains.
The whole point about a log structured file system is that you write
all updates of data and metadata into a sequential stream. This may cause
updates to be delayed significantly, but it should not cause them to be
reordered. For a definition of log structured file systems, look on Wikipedia.
The article is quite comprehensive.
Actually, btrfs is not implemented as real log-structured file system,
but the COW logging of data and metadata effectively should give the same
semantics as a log-structured file system. If it doesn't, this semantics
is broken. Either by Chris Mason being bonehead as well or because btrfs
is not ready for prime time yet.
I think the main point here that counters the argument "POSIX allows
this" is that POSIX actually defines an order of operations on file
systems, at least as long as the system is running: Operations are
performed in order, and metadata operations are atomic. If
you advertise your file system as robust, as both ext4 and to an even
higher degree btrfs do, you have to preserve this order, and keep
metadata operations atomic (the latter is something ReiserFS doesn't).
Everything else breaks the promise of being robust. Under POSIX, it is
actually allowed to have non-robust file systems. This is deliberately
meant for bonehead filesystem implementors, because there are so
many ;-). Actually, this is meant as performance tradeoff. However, with
delayed allocation of data blocks, also delaying metadata updates, gives
a performance improvement, too!
to post comments)