Aristotle:
Thank you for the explanation. What you wrote makes sense. The
papers that I referenced [1] didn't analyze the consequences of data
loss failures, only the mechanism (if any) that the filesystem code
has for detecting and responding to failures. Those papers seem to
suggest that reiser3 is better than the others (but not perfect) at
the goal of detecting more possible failures, handling them in a fail-
safe manner (thus trading off availability to gain correctness) and
handling a variety of failures in a consistent way. However, if
there is an error which isn't detected by the filesystem code (such
as a silent mis-write), then I can see how the less redundant reiser3
data structure is more brittle.
Thanks again.
And for my own proclivities, reiserX goes too far toward the
performance end of the scale.
...
Hence my general dislike of reiserX.
Here are some personal proclivities of my own:
I don't like ext3. It seems to be engineered "ad-hoc". The recent
revelations that (a) it turns write-barriers off by default, (b)
nobody knows how much performance delta we're talking about, (c)
nobody knows how much safety delta we're talking about, is just the
latest detail to make me think that ext3 is engineered primarily by
ad-hoc response to complaints (or by ad-hoc improvements). I won't
go into more detail.
I like reiser3 in general for the reasons that I listed above.
However, "in general" is probably not the right way to choose a local
filesystem. Rather, the specific use case probably makes all the
difference. For Tahoe LAFS [2] storage servers, reiser3 is probably
a good choice because it runs on Linux, is fast, and packs small
files for better space efficiency. Tahoe does not rely on local
filesystems for data correctness or longevity, so the chance of data
corruption or loss isn't that important of a criterion, but reiser3's
tendency (mentioned above) to fail loudly and fail-stop is probably
better operationally than the alternative of grinding along quietly
while losing or corrupting data or suffering reduced performance.
Also the fact that other large data-farming operations like the
Internet Archive, Mozy, and EMC Centera [4] have used reiser3
extensively gives me confidence. Finally, the fact that reiser3 is
old and does not get tweaked or improved is reassuring -- the worst
failures we're likely to encounter are new bugs or new filesystem
"improvements" that we didn't understand.
I like ZFS, and I'm happy using it on (Free Software, Open Source)
Solaris. My web server, http://zooko.com is running Nexenta [3]
which uses ZFS by default.
I like BTRFS, and furthermore I predict that it will be a huge
success in a few years because (as Andy Isaacson showed me), you can
upgrade your ext3 filesystem in place to BTRFS, and even revert it
again to the state that it was in before you upgraded it to BTRFS. I
think the main reason that ext3 is the de facto standard nowadays is
because ext3 was so data-backwards-compatible with ext2, and since
BTRFS is highly data-backwards-compatible with ext3 (as well as
having many other great features, as well as being architected by
Chris Mason who was responsible for much of the good stuff in
reiser3, as well as being funded and supported by Oracle), then it is
sure to be a winner.
Regards,
Zooko
[1] http://allmydata.org/trac/tahoe/wiki/Bibliography#LocalFilesystems
[2] http://allmydata.org
[3] http://nexenta.org
[4] http://lkml.org/lkml/2008/5/18/260
