Toward merging reiser4
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:
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.
| Index entries for this article | |
|---|---|
| Kernel | Filesystems/Reiser4 |
Posted Sep 15, 2005 2:12 UTC (Thu)
by bk (guest, #25617)
[Link] (1 responses)
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.
Posted Sep 22, 2005 21:24 UTC (Thu)
by xorbe (guest, #3165)
[Link]
Posted Sep 15, 2005 3:26 UTC (Thu)
by ChrisWhite (guest, #24268)
[Link]
Posted Sep 15, 2005 14:00 UTC (Thu)
by zooko (guest, #2589)
[Link]
Posted Sep 15, 2005 18:36 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Sep 19, 2005 22:03 UTC (Mon)
by csawtell (guest, #986)
[Link] (1 responses)
Posted Oct 9, 2005 14:01 UTC (Sun)
by Zam (guest, #32971)
[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.Toward merging reiser4
> a less mature, more bug-prone yet faster Toward merging reiser4
> version of reiserfs3 is not interesting
... to you. Maybe some others are interested.
> Otherwise it need not be called reiser4;
> "reiser3.7" would be more accurate.
Why do people waste time arguing about version
numbers... just call it anything and be done
with it.
Reiser 4 didn't meet the deadline by the way. There was simply not enough
time to get the fixes in. Will it make it into 2.6.15? Who knows, and as
Andrew said, filesystems can find their way in at any time.
Toward merging reiser4
Maybe once "reiser3.7" is in Linus's tree then the distros (from whom I get my kernels) will be willing to re-enable the option of the advanced and dangerous features of reiser4.Toward merging reiser4
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
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.Toward merging reiser4
Would you please send the details (kernel version. fsck version, fsck
report) to the reiserfs-list@namesys.com ? I can say that users
don't report about data loss usually.