It does (did?) Have a very serious bug with fsck though. If you have an image of a resierfs file system on a reisferfs filesystem the fsck would merge the two like a maniac leaving the whole thing broken. This meant that it isn't suitable for virtual machines, disk image backups, or other similar situations. I hit that one a few times and it made me switch to ext3 once it was stable.

An image as in a dd of another file system? That's a pretty serious bug - I'm wondering how it'd even find that, if it's searching its b-tree. This sounds like it's going past file system / meta data and looking at file content.

I can't imagine why a fsck tool would dive into payload like that - do you have some more information about this bug, as I can't find reference to it. Most of my residual reiserfs boxes are VM's themselves, so I'm unlikely to hit it, but some mitigation would be comforting.

> An image as in a dd of another file system? That's a pretty serious bug - I'm wondering how it'd even find that, if it's searching its b-tree. This sounds like it's going past file system / meta data and looking at file content.

Yep exactly that. The whole reason it did it was that it sometimes needed to recover from a corrupted b-tree but it leaves enough markers around that it could rebuild the b-tree by scanning all the blocks.

https://en.wikipedia.org/wiki/ReiserFS#fsck

I can't find a better link at the moment, the lkml link on wikipedia is dead and it's hard to search for, but at the time it was well known for this kind of bug.

EDIT:

Until I learned about that bug (the hard way at first) the ability of it to rebuild itself after a problem like that was actually incredibly useful, it'd recover really nicely from a bad disk, finding just what it could manage to find.

I heard that it was renamed to KillerFS