Toward merging reiser4 [LWN.net]

The reiser4 filesystem has been the subject of a long, ongoing conversation for many months; look under "reiser4" in the LWN Kernel Page Index for previous coverage on this page. The reiser4 developers have been working hard to get their new filesystem merged into the mainline kernel, and they believe that the time has come. To that end, Hans Reiser has posted a list of concerns raised by others. His hope is to get definitive answers on what has to be done to get reiser4 in, hopefully for 2.6.14.

One of the big issues since the beginning has been the reiser4 metafiles feature, where every file can, itself, be treated as a directory with the file's attributes accessible as files in their own right. This feature raised many eyebrows just by looking weird and non-Unix-like, but the real issue was one of locking. The Linux virtual filesystem code is simply not set up to handle files as directories, so it is easy for a user to deadlock the system. Even Hans Reiser, a strong defender of the metafile feature, sees these deadlocks as an undesirable thing.

So, while reiser4 has been in -mm for quite some time, the metafile feature has been disabled. There is no talk of turning it back on for a mainline merge; the real issue, instead, is whether the code should be allowed to remain at all. The consensus on the kernel side would appear to be that unused code does not belong in the kernel, so the metafile implementation is likely to be removed altogether. Someday, if the locking issues are resolved, it might yet return.

Reiser4 has long had trouble working with 4K kernel stacks (see last week's Kernel Page). It would appear that this issue has now been resolved. Another complaint which has been raised has to do with a large number of debugging tests in the code itself; some developers see it as clutter and would like it to be removed. Here, however, Andrew Morton has sided with the reiser4 hackers and told them to leave the tests in.

Reiser4 implements a couple of its own types for condition variables and linked lists. In both cases, it is thought that the in-kernel primitives could be used, rather than introducing new, redundant types. Those will probably have to be fixed before this code can be merged.

The end result is that quite a bit of work remains to be done, meaning that it is unlikely to be ready before 2.6.14 closes to new features. Andrew has hinted that reiser4 might just slip in after the deadline, though:

But something like a brand new filesystem can go in pretty much any time, as long as it compiles. Because it can't break anyone's current setup.

The one issue which, interestingly, has not come up in the recent discussion has been the plugin architecture used by reiser4. To a number of developers, that sort of feature does not belong at the individual filesystem level; it should, instead, be made part of the VFS layer and made available to all filesystems. It would appear that a more moderate viewpoint, allowing the feature to be merged now with the idea of shifting it up into the VFS over time, has won out.

(Log in to post comments)

Toward merging reiser4

Posted Sep 15, 2005 2:12 UTC (Thu) by bk (guest, #25617) [Link]

I've said it before and I'll say it again: a less mature, more bug-prone yet faster version of reiserfs3 is not interesting, nor is it worth the hassle of upgrading my disk storage.

A radically feature-enhanced, faster yet less mature reiser4, OTOH, may be worth the trouble depending on how immature it is and how valuable the new feature set is.

It's great that it's getting closer to being merged, I'd like to see the metadata pseudofile functionality as a compile-time option. Otherwise it need not be called reiser4; "reiser3.7" would be more accurate.

Toward merging reiser4

Posted Sep 15, 2005 18:36 UTC (Thu) by iabervon (subscriber, #722) [Link]

It seemed to me like nobody was really complaining about having a bunch of debugging tests; they were complaining that they used mysterious messages, that they could try to reboot the computer, that they used reiser4-specific macros instead of the standard ones, and that some of them checked for cases that the kernel would catch automatically. The general concept is, of course, fine, and the long list of complaints wasn't supposed to be an argument against doing it at all.

Toward merging reiser4

Posted Sep 19, 2005 22:03 UTC (Mon) by csawtell (guest, #986) [Link]

I have been running Reiser4 for some months on a ThinkPad. It seems to be faster than any other file system. I do a fsck.reiser4 every week, there is a consistent report of damage to the file system right at the start of the fsck run, but this is always corrected by fsck when using the --build-fs option flag. I have yet to lose any data, which by the way happened more than once when I was using XFS. I would like to see Reiser4 in the mainline kernel as soon as possible. It works for me. Thank you Hans.