The future of Reiser4 was raised on the lkml [1], with the filesystem's creator, Hans Reiser [interview [2]], awaiting his May 7'th trial [3] [story [4]]. Concerns that the filesystem wasn't being maintained were laid to rest when Andrew Morton [interview [5]] stated, "the namesys engineers continue to maintain reiser4 and I continue to receive patches for it." He further added, "the namesys guys are responsive and play well with others." As to why the filesystem hasn't yet been merged into the 2.6 kernel, Andrew explained, "to get it unstuck we'd need a general push, get people looking at and testing the code, get the vendors to have a serious think about it, etc. We could do that - it'd require that the namesys people (and I) start making threatening noises about merging it, I guess." He then made joking reference to the recent debate regarding the new CPU schedulers [story [6]], "or we could move all the reiser4 code into kernel/sched.c - that seems to get people fired up."
Namesys developer and author of the Reiser4 encryption and compression plugins, Edward Shiskin, offered some updates. Replying to some comments about the need to remove plugins from the Reiser4 code he explained, "the popular opinion that plugins make more sense in the VFS is a great delusion, as plugins are entities related to reiser4 disk layouts." In an earlier thread it had been suggested that the plugins were misnamed and would be better called an internal abstraction layer [story [7]]. Edward went on to note, "currently there are two namesys employees working [on Reiser4] mostly on enthusiasm." He linked to a wiki page [8] listing known issues with the code needing to be fixed before it's likely to be merged into the 2.6 kernel, "the main issues here are xattrs and support for blocksize != pagesize. I think that adding xattrs will take ~1 month of full-time working. Not sure about blocksize support." When it was noted that other filesystems have already been merged without support for either of these features, Edward said that they'd lower their priority and finish up with the other remaining issues left on the old todo list and resume the merge discussion at that time.
From: Eric Hopper [email blocked] To: linux-kernel Subject: Question about Reiser4 Date: Sun, 22 Apr 2007 19:00:46 -0700 I know that this whole effort has been put in disarray by the prosecution of Hans Reiser, but I'm curious as to its status. Is Reiser4 going to be going into the Linus kernel anytime soon? Is there somewhere I should be looking to find this out without wasting bandwidth here? I'm not an LKML subscriber. Thanks, -- Eric Hopper (http://www.omnifarious.org/~hopper/ [9])
From: Rik van Riel [10] [email blocked] Subject: Re: Question about Reiser4 Date: Sun, 22 Apr 2007 23:56:11 -0400 Eric Hopper wrote: > I know that this whole effort has been put in disarray by the > prosecution of Hans Reiser, but I'm curious as to its status. It was in disarray well before. Many of the reiser4 features, like filesystem plugins, make more technical sense in the Linux VFS, but made more business sense for Namesys as a reiserfs 4 thing. That lead to a stalemate. > Is Reiser4 going to be going into the Linus kernel anytime soon? I wouldn't count on it.
From: William Heimbigner [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 03:56:00 +0000 (GMT) > Eric Hopper wrote: >> I know that this whole effort has been put in disarray by the >> prosecution of Hans Reiser, but I'm curious as to its status. > > It was in disarray well before. Many of the reiser4 features, > like filesystem plugins, make more technical sense in the Linux > VFS, but made more business sense for Namesys as a reiserfs 4 > thing. That lead to a stalemate. > Shouldn't it be a matter of stability though? Benchmarks suggest that reiser4 is a good file system; reiser4 is the successor to the already-accepted reiserfs; we've got experimental ext4 support but no reiser4 support, etc. I don't see why something like plugins should matter. If it works enough to be marked as experimental, why shouldn't reiser4 support be included? It's a pain for me personally to have to patch any kernel with reiser4 support so I can use the reiser4 fs. William Heimbigner [email blocked]
From: Rik van Riel [11] [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 01:47:04 -0400 William Heimbigner wrote: >> Eric Hopper wrote: >>> I know that this whole effort has been put in disarray by the >>> prosecution of Hans Reiser, but I'm curious as to its status. >> >> It was in disarray well before. Many of the reiser4 features, >> like filesystem plugins, make more technical sense in the Linux >> VFS, but made more business sense for Namesys as a reiserfs 4 >> thing. That lead to a stalemate. >> > Shouldn't it be a matter of stability though? A lot of other things matter. Things like a willingness to maintain the code after it gets merged, or at least turning the code into something the community is willing to maintain if the original developers stop maintaining it. > Benchmarks suggest that > reiser4 is a good file system; reiser4 is the successor to the > already-accepted reiserfs; we've got experimental ext4 support but no > reiser4 support, etc. Namesys kind of abandoned reiserfs after work on reiser4 started. Taking in a new code base on such a track record is not a good idea when the code is not in a shape where the community wants to maintain it. > I don't see why something like plugins should matter. If it works enough > to be marked as experimental, why shouldn't reiser4 support be included? > It's a pain for me personally to have to patch any kernel with reiser4 > support so I can use the reiser4 fs. You basically have three options: 1) keep patching every time you upgrade the kernel 2) use another filesystem 3) become the new reiser4 maintainer and turn the code into something that Linus is willing to accept -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic.
From: William Heimbigner [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 05:57:53 +0000 (GMT) > William Heimbigner wrote: >> > Eric Hopper wrote: >> > > I know that this whole effort has been put in disarray by the >> > > prosecution of Hans Reiser, but I'm curious as to its status. >> > >> > It was in disarray well before. Many of the reiser4 features, >> > like filesystem plugins, make more technical sense in the Linux >> > VFS, but made more business sense for Namesys as a reiserfs 4 >> > thing. That lead to a stalemate. >> > >> Shouldn't it be a matter of stability though? > > A lot of other things matter. Things like a willingness to > maintain the code after it gets merged, or at least turning > the code into something the community is willing to maintain > if the original developers stop maintaining it. > >> Benchmarks suggest that reiser4 is a good file system; reiser4 is the >> successor to the already-accepted reiserfs; we've got experimental ext4 >> support but no reiser4 support, etc. > > Namesys kind of abandoned reiserfs after work on reiser4 > started. Taking in a new code base on such a track record > is not a good idea when the code is not in a shape where > the community wants to maintain it. > >> I don't see why something like plugins should matter. If it works enough >> to be marked as experimental, why shouldn't reiser4 support be included? >> It's a pain for me personally to have to patch any kernel with reiser4 >> support so I can use the reiser4 fs. > > You basically have three options: > > 1) keep patching every time you upgrade the kernel > > 2) use another filesystem > > 3) become the new reiser4 maintainer and turn the code > into something that Linus is willing to accept I suppose. I have a feeling there's an underlying issue behind "code standards" (and even then, I think that code standards is ultimately an excuse for not integrating reiser4 support into the kernel, but that's just my opinion). However, is the code really in such a shape that the community doesn't want to maintain it? Obviously there's a significant number of people interested in reiser4 - if there weren't, questions like this wouldn't keep getting asked. William Heimbigner [email blocked]
From: Rik van Riel [12] [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 02:07:46 -0400 William Heimbigner wrote: > However, is the code really in such a shape that the > community doesn't want to maintain it? Obviously there's a significant > number of people interested in reiser4 - if there weren't, questions > like this wouldn't keep getting asked. There are people interested in using it, yes. However, nobody appears to have stepped up to maintain the code. If somebody really wanted to maintain the code, there would be a new maintainer already. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic.
From: William Heimbigner [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 06:14:04 +0000 (GMT) On Mon, 23 Apr 2007, Rik van Riel wrote: > William Heimbigner wrote: > >> However, is the code really in such a shape that the community doesn't >> want to maintain it? Obviously there's a significant number of people >> interested in reiser4 - if there weren't, questions like this wouldn't >> keep getting asked. > > There are people interested in using it, yes. > > However, nobody appears to have stepped up to maintain the code. > If somebody really wanted to maintain the code, there would be a > new maintainer already. On that note, what exactly is wanted for (assuming there was a maintainer) reiser4 to be suitable for inclusion in the kernel? To my knowledge (and I'll admit, I haven't looked in to it very far) the primary reason for rejection was that it broke coding standards. If there was 1) a maintainer and 2) code that didn't break "coding standards", would it be included in the kernel? William Heimbigner [email blocked]
From: Rik van Riel [13] [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 02:20:36 -0400 William Heimbigner wrote: > If there was 1) a maintainer and 2) code that didn't break "coding > standards", would it be included in the kernel? While I cannot speak for Linus and Andrew, code that fulfills these criteria (and is useful to have - reiser4 seems to have enough user interest) usually gets accepted. http://kernelnewbies.org/UpstreamMerge [14] has some hints. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic.
From: William Heimbigner [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 06:42:24 +0000 (GMT) On Mon, 23 Apr 2007, Rik van Riel wrote: > William Heimbigner wrote: > >> If there was 1) a maintainer and 2) code that didn't break "coding >> standards", would it be included in the kernel? > > While I cannot speak for Linus and Andrew, code that fulfills > these criteria (and is useful to have - reiser4 seems to have > enough user interest) usually gets accepted. > > http://kernelnewbies.org/UpstreamMerge [15] has some hints. So in conclusion / to answer Eric's question, 1) reiser4 needs a maintainer 2) reiser4 needs the code quality cleaned up 3) Until those two things happen, it's extremely unlikely that it will be included in the kernel. Correct? William Heimbigner [email blocked]
From: Andrew Morton [16] [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 01:04:45 -0700 On Mon, 23 Apr 2007 06:42:24 +0000 (GMT) William Heimbigner [email blocked] wrote: > > On Mon, 23 Apr 2007, Rik van Riel wrote: > > William Heimbigner wrote: > > > >> If there was 1) a maintainer and 2) code that didn't break "coding > >> standards", would it be included in the kernel? > > > > While I cannot speak for Linus and Andrew, code that fulfills > > these criteria (and is useful to have - reiser4 seems to have > > enough user interest) usually gets accepted. > > > > http://kernelnewbies.org/UpstreamMerge [17] has some hints. > > So in conclusion / to answer Eric's question, > 1) reiser4 needs a maintainer > 2) reiser4 needs the code quality cleaned up > 3) Until those two things happen, it's extremely unlikely that it will be > included in the kernel. > The namesys engineers continue to maintain reiser4 and I continue to receive patches for it. Right now I'd say that the main blockages for reiser4 are a) the developers aren't presently asking for inclusion (afaik) and b) lack of reviewing effort from other kernel developers.
From: Eric Hopper [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 06:52:16 -0700 On Mon, Apr 23, 2007 at 01:04:45AM -0700, Andrew Morton wrote: > The namesys engineers continue to maintain reiser4 and I continue to > receive patches for it. > > Right now I'd say that the main blockages for reiser4 are a) the developers > aren't presently asking for inclusion (afaik) and b) lack of reviewing > effort from other kernel developers. If someone else started asking for it to be included and responded to requests for the various code changes required to increase its quality to the required level, wouldn't that be enough? Basically, if someone forked it. Or does it specifically have to be namesys engineers? Oh, two things really interest me about Reiser4. First, I despise having to care about how many tiny files I leave lying around when writing a program. Berkeley DB and its ilk are evil, evil programs that obscure data and make things harder. Secondly, the moves Reiser4 has made towards having actual transactions at the filesystem level also intrigue me. I want to use the filesystem as a DB. IMHO, there is no reason that filesystems shouldn't be a DB sans query language. If there were a more DB-like way to deal with filesystems, I think that it would be that much easier to make something that was a decent replacement for NFS and actually worked. Sadly, unless someone pays me to maintain it, I can't do the fork myself, and I likely wouldn't anyway as being a kernel hacker of something as important as a filesystem is a full-time job and I have other things that interest me a lot more. Just curious, -- Eric Hopper (http://www.omnifarious.org/~hopper/ [18])
From: Andrew Morton [19] [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 10:40:42 -0700 On Mon, 23 Apr 2007 06:52:16 -0700 Eric Hopper [email blocked] wrote: > On Mon, Apr 23, 2007 at 01:04:45AM -0700, Andrew Morton wrote: > > The namesys engineers continue to maintain reiser4 and I continue to > > receive patches for it. > > > > Right now I'd say that the main blockages for reiser4 are a) the developers > > aren't presently asking for inclusion (afaik) and b) lack of reviewing > > effort from other kernel developers. > > If someone else started asking for it to be included and responded to > requests for the various code changes required to increase its quality > to the required level, wouldn't that be enough? Basically, if someone > forked it. > > Or does it specifically have to be namesys engineers? That's not where the problem lies - the namesys guys are responsive and play well with others. But they haven't received any "requests for the various code changes" in over a year. And I'm in the same boat as most everyone else: I haven't looked at the reiser4 code in ages. Right now I don't have anything like a list of outstanding technical issues. To get it unstuck we'd need a general push, get people looking at and testing the code, get the vendors to have a serious think about it, etc. We could do that - it'd require that the namesys people (and I) start making threatening noises about merging it, I guess. Or we could move all the reiser4 code into kernel/sched.c - that seems to get people fired up.
From: Theodore Tso [email blocked] Subject: Re: Question about Reiser4 Date: Mon, 23 Apr 2007 18:56:41 -0400 On Mon, Apr 23, 2007 at 06:52:16AM -0700, Eric Hopper wrote: > Oh, two things really interest me about Reiser4. First, I despise > having to care about how many tiny files I leave lying around when > writing a program. Berkeley DB and its ilk are evil, evil programs that > obscure data and make things harder. Secondly, the moves Reiser4 has > made towards having actual transactions at the filesystem level also > intrigue me. > > I want to use the filesystem as a DB. IMHO, there is no reason that > filesystems shouldn't be a DB sans query language. If there were a more > DB-like way to deal with filesystems, I think that it would be that much > easier to make something that was a decent replacement for NFS and > actually worked. One of the big problems of using a filesystem as a DB is the system call overheads. If you use huge numbers of tiny files, then each attempt read an atom of information from the DB takes three system calls --- an open(), read(), and close(), with all of the overheads in terms of dentry and inode cache. Hans of course had a solution to this problem --- namely the sys_reiser4 system call, where you download a program to the kernel to execute a open/read/close via a single system call, and which returns the combined results to userspace. But now you have more complexity since there is now a reseir4-specific interpreter embeddeed in the kernel, the userspace application needs to write the equivalent of an channel program such as what was found in an IBM/360 mainframe (need I mention this can be a rich source of security bugs), and then the userspace application *still* needs to parse the result returned by the sys_reiser4() system call? So it adds a huge amount of complexity, and at the end of the day, given that you don't have the search capability, it is (a) less functional, (b) more complexitated, and (c) probably less performant than simply calling out to a database. > Sadly, unless someone pays me to maintain it, I can't do the fork > myself, and I likely wouldn't anyway as being a kernel hacker of > something as important as a filesystem is a full-time job and I have > other things that interest me a lot more. Unfortunately, the way OSS works is that you either (a) have to do the work yourself, (b) convince someone else to do the work, or (c) convince someone that it's worth paying you to do it. Personally, if I controlled large budget for Linux filesystem development, I'd put a lot more money into something like Val's chunkfs idea than resier4. Being able to have filesystems designed for fast recovery given disks getting larger and larger (but not more reliable), is a whole lot more improtant than trying to create an alternate solution to an already solved problem --- namely that of a database. When you consider that a similar idea, WinFS, was partially responsible for delaying Vista by years due to the complexity of shoving a database where it has no place being, it's another reason why I personally think that chunkfs is a much more promising avenue for future filesystem investment than reiserfs. But hey, the advantage of Open Source is that if *you* want to work on Reiser4, you're perfectly free to do so. My personal opinion is that it'd be a waste of your time, but you're free to spend your time whichever way that you want. What you don't get do is whine about how other people get to spend *their* time, or *their* money. - Ted
From: Edward Shishkin [email blocked] Subject: Re: Question about Reiser4 Date: Tue, 24 Apr 2007 18:43:59 +0400 Hello everyone. >Begin forwarded message: > >Date: 23 Apr 2007 21:05:13 +0200 >From: Andi Kleen [email blocked] >Cc: Eric Hopper [email blocked], linux-kernel >Subject: Re: Question about Reiser4 > > >Andrew Morton [email blocked] writes: > > >>To get it unstuck we'd need a general push, get people looking at and testing >>the code, get the vendors to have a serious think about it, etc. We could do >>that - it'd require that the namesys people (and I) start making threatening >>noises about merging it, I guess. >> >> > >My impression was that a lot of negative discussion came out of some of the >user interface inventions in r4 (like sys_reiser4 and the >new incompatible EA interface). > > > sys_reiser4 and metas interface were removed (current -mm stuff doesn't contain them). >I guess a good strategy to get it going would be to extract just >a "core reiser4" out of it that is just a file system without >any new interfaces like this. > > > I think that current reiser4 is exactly that "core", which responds solely to VFS. The popular opinion that plugins make more sense in the VFS is a great delusion, as plugins are entities related to reiser4 disk layouts. There are many aspects where plugin architecture is useful, I tried to describe one of them -- backward compatibility that was got with minimal efforts: http://dev.namesys.com/Version4.X.Y [20] If this needs more comments, then we will proceed the documentation. >I would expect that reviewing that would be much smoother >because people could actually concentrate on the technical details. > >-Andi > > > Other comments: 1. Why Namesys developers aren't presently asking for inclusion? Because there are unaddressed items in this todo list: http://pub.namesys.com/Reiser4/ToDo [21] The main issues here are xattrs and support for blocksize != pagesize. I think that adding xattrs will take ~1 month of full-time working. Not sure about blocksize support. Also, the statement about "main issues" may be too optimistic. Let's try to estimate.. 2. Who will maintain this? Currently there are two namesys employees working mostly on enthusiasm. Divide them into 2 file systems, plus many people who really help with fixing problems. So we need to estimate how dramatic the situation with reiser4 is (experts are welcome). In the worst case (no funding for this in the perspective) I hope to devote ~25% of my working time to this project. Vladimir might want to add something here, but he is sick for now. By the way, he has its own opinion what part of current reiser4 should go to mainline (separating tail's support (which makes things complicated) as special incremental update available on our website). Thanks, Edward.
From: Andi Kleen [email blocked] Subject: Re: Question about Reiser4 Date: Tue, 24 Apr 2007 21:39:21 +0200 > Because there are unaddressed items in this todo list: > http://pub.namesys.com/Reiser4/ToDo [22] > The main issues here are xattrs and support for blocksize != pagesize. I would consider both to be optional. We have various file systems in tree that don't support either (e.g. JFS only supports 4K blocks and OCFS2 doesn't support xattr) They shouldn't block merging. > 2. Who will maintain this? > > Currently there are two namesys employees working mostly on > enthusiasm. Divide them into 2 file systems, plus many people who > really help with fixing problems. Merging will probably be a peak of work for the necessary changes, then hopefully the work will be less once you're in tree because you don't need to track mainline anymore (assuming not to many bugs come in from users) -Andi
From: Edward Shishkin [email blocked] Subject: Re: Question about Reiser4 Date: Wed, 25 Apr 2007 18:35:03 +0400 Andi Kleen wrote: >>Because there are unaddressed items in this todo list: >>http://pub.namesys.com/Reiser4/ToDo [23] >>The main issues here are xattrs and support for blocksize != pagesize. >> >> > >I would consider both to be optional. We have various file systems >in tree that don't support either (e.g. JFS only supports 4K blocks >and OCFS2 doesn't support xattr) They shouldn't block merging. > > > xattrs also were considered as some guarantee of vendor support. If possible, then we'll address it as low-priority issue. Maybe somebody will help.. (xattrs support should go as incremental update of FPL-subversion for reiser4 kernel module and reiser4progs). >>2. Who will maintain this? >> >>Currently there are two namesys employees working mostly on >>enthusiasm. Divide them into 2 file systems, plus many people who >>really help with fixing problems. >> >> > >Merging will probably be a peak of work for the necessary changes, >then hopefully the work will be less once you're in tree because >you don't need to track mainline anymore >(assuming not to many bugs come in from users) > >-Andi > > Hope we survive this, at least such peaks is not something new in our practice. Well, gentlemen, so we'll address other items (except #26, 27) and resume this discussion. Thanks, Edward.
Related Links:
- Archive of above thread [24]
- KernelTrap interview with Rik van Riel [25]
- KernelTrap interview with Andrew Morton [26]