Disgusted

[pphaneuf]

A bit of a technical post, since my other diary is currently broken (yay for computers).

Reiserfs is terrible. I don't know much about the design, but the style of the code leaves much to be desired.

You remember how doing fread() and fwrite() of structures to disk is a bad idea? Well, that's exactly how the reiserfs superblock is written, including a bunch of pointer members. Wow, stylin'.

The journal flushing algorithm is recursive. Recursive. In the kernel. It has a 4k stack now. Running out of stack will make it panic. Hope you don't have too many transaction piling up between two scheduling of the reiserfs journal flushing thread (people who know me also know what I think of threads).

Is this serious? Jebus, I need a drink.

Comments

[swestrup]

Eep! I'm using Reiserfs on my server, because it seemed competant! At least, if you read the whitepapers, the author is worrying about the right things.

Now I'm suddenly wondering if I should find a way to migrate to XFS.

[pphaneuf.livejournal.com]

Oh, I didn't mention the testing we've done? In choosing the best filesystem for our on-disk backup solution, we made a little program that does all sorts of evil things to your partition, like write random data all over. Reiserfs panicked almost immediately, often leaving an unrecoverable filesystem.

We didn't test a wide range of filesystems, though, only reiserfs, ext3 and vfat. Unsurprisingly, vfat was very resilient to crap (normal, considering the way it was historically used), but ext3 did rather well.

Reiserfs never smelled good to me. Froze my system on high disk I/O load in my SuSE 7.x. Would randomly replace the content of files with the content of deleted files in the SuSE 8.x era when my system crashed (this was on a laptop, running out of battery happens, and I wasn't too impressed by my XF86Config being replaced with some GIF from my browser cache).

I like the old, stable and very much tested codebase of ext2, with super-simple (as in "hard to get wrong") journaling at the block device layer added in ext3. Not the fastest (but *almost*), and not the fanciest (but the *workingest*).

I've also met Stephen Tweedie in person, and before learning who he was, I found myself amazed at how massively smart and reasonable that person was.

[http://users.livejournal.com/hub_/]

try xfs and jfs.

[pphaneuf.livejournal.com]

Why? Do you need things like being able to reserve disk bandwidth?

[http://users.livejournal.com/hub_/]

And then read Theo de Raadt comment about Linux development.

Sometime I wonder if he is not right.

[joenotcharles.livejournal.com]

Recursive? That's just [i]lazy[/i].

[pphaneuf.livejournal.com]

And with a 4k stack, also stupid.

BTW, those tags didn't get expanded there.

[sailorfrag.livejournal.com]

My biggest complaint about reiserfs (and xfs too, now that I'm using it) is that to fsck, you can't have it mounted read only. That's something extremely useful as a root filesystem. You take it for granted with ext2/ext3, yet it's actually a rare feature, apparently. Fortunately, it seems that reiserfs and xfs need fsck far less frequently than ext3 and especially ext2.

[pphaneuf.livejournal.com]

ext3 doesn't need fsck any more frequently than reiserfs or xfs. They just have extra-safe defaults of checking anywya. I like extra-safe. I don't like idiotic code in my filesystem. Use tune2fs to change to "never" (change both the number of mounts and days).

If you did the same with reiserfs, you'd probably randomly corrupt your filesystem anyway. Reiserfs' fsck usually makes things worse. They don't run it because it's a bad idea.

[sailorfrag.livejournal.com]

I'd accept your claim, except that the auto fsck in ext3 always finds errors when it runs for me. On the other hand, since reiserfsck doesn't normally run at all, I guess I can't really tell if it's hiding errors that should probably be fixed.

It's interesting that you claim reiserfsck is more sensitive to problems... in my experience running reiserfs for a few years, I've only had to boot off a CD to run reiserfsck --rebuild-tree twice. One of those times was because a drive was dying (which I discovered soon after), and the other seemed to be random death due to power failure (it worked perfectly after).

On the other hand, I've had ext3 eat itself several times on me, and I don't even usually have a computer running ext3 (guess why). Disclaimer: this anecdotal evidence may be tainted by the fact that at least some of those times the hardware was later deemed bad. I don't remember if I had an example of good hardware resulting in ext3 eating itself. Still, it's made me wary of ext3, even if it's not a fair test.

Actually, I think one of the times that ext3 was failing on me was when I was trying to get poke (my p150 answering machine) to work in January. I eventually gave up on the drive and went to NFS root. Worked perfectly after that! Maybe I should just give up on old and/or cheap hard drives entirely.

[pphaneuf.livejournal.com]

Our very own Peter Zion has cases where power failure can corrupt reiserfs. When you go and look for it, you can make it happen within a few reboots. Get together with James de Boer and discuss reiserfs vs ext3 with him, he wrote a work report about it.

[sailorfrag.livejournal.com]

I'm sure you're not lying. And, uh, the only drives I have with reiserfs happen to have data that I'd prefer to keep (although it would be possible to re-acquire), so I'll take your word for it :-)