This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: Linux

Reiser4 and the politics of the kernel

By Bruce Byfield on August 04, 2006 (8:00:00 AM)

Share    Print    Comments   

Why is the Reiser4 filesystem not in the Linux kernel? Recently, the question has been discussed on the kernel mailing list, and it's not a pretty sight; anyone who imagines that kernel development is a rational discourse only needs to look at the exchange to be disillusioned. While both sides claim to be arguing technical merits, the discussion spills over into a debate about the advantages of established procedures and policies. It's also turned into a clash of personalities.

Reiser4 is the successor to ReiserFS (a.k.a. Reiser3), a journaled filesystem that has been in the kernel since version 2.4.1, and that also faced a rocky road to inclusion. Both are developed by Namesys, a company fronted by Hans Reiser, with sponsorship from Linspire and the Defense Advance Research Projects Agency. According to Namesys, Reiser4 offers twice the speed of other filesystems, as well as greater efficiency in file allocation and military-grade security. It has attracted a loyal group of users, and, while not in the official kernel, is included in Andrew Morton's experimental -mm kernel sources.

Discussions about Reiser4's status have flared periodically for months. The current discussion started when Diego Calleja posted a document entitled "Why Reiser4 is not in the Linux Kernel" on the Kernel Newbies wiki. Since the document was not issued by Linus Torvalds or Andrew Morton, it is not an official statement. Calleja describes it as "a sort of Linux kernel mailing list opinion" -- that is, as a summary of prevailing views, written by him and edited by several others.

Reiser responded with a rebuttal on the kernel mailing list. Besides the main question, the resulting thread raised side issues including the reception of ext4 by kernel developers, the desirability of testing new features in distributions before the kernel, whether small patches are integrated faster than larger ones, and whether Reiser ignores bugs in ReiserFS in order to focus on Reiser4. Throughout these exchanges, both sides strained to keep the conversation polite, but neither completely resisted snide remarks or the temptation to lecture the other, and disagreements were as likely to be over half-truths or preferences as technical points.

Standard procedures vs. convention and favoritism

According to Calleja, the main explanation for Reiser4's exclusion is that it is not yet sufficiently tested. Reiser complains that this criticism is not only untrue, but a double-bind. More than one feature is marked as experimental in the kernel, and one of the points of inclusion is to ensure thorough testing. To Calleja's suggestion that he try the tactic of introducing Reiser4 through a distribution, Reiser replies that kernel developers are far more suitable than the average user of a distribution.

On the technical side, the debate over Reiser4 centers on the fact that that it uses its own structure for plugins, rather than those that already exist in the kernel's Virtual File System (VFS) layer. Calleja speaks for many kernel developers -- probably the majority -- when he says, "The code that needs to be merged must adapt to Linux's point of view, no matter how much submitters disagree. The Linux kernel is community-oriented, and it's the community that must take the decisions. You can't impose your point of view on the rest of the kernel developers."

To complicate matters, Reiser4's approach lands the filesystem in the middle of a longstanding convention of avoiding plugins in the kernel, mainly to avoid architectural complications, but also to discourage proprietary drivers that circumvent the kernel's release under the GNU General Public License. According to Torvalds, "if a filesystem wants to do something fancy, it needs to do so with the Virtual File System (VFS) Layer, not as some plugin architecture of its own. We already have exactly the plugin interface we need, and it literally is the VFS interfaces."

Similarly, when Reiser formally requested that Reiser4 be accepted into the kernel in September 2005, Christoph Hellwig, one of the lead maintainers for filesystems in the kernel, noted that its source code did not follow the kernel coding style. Unless it did, several developers suggested, other programmers would have a hard time contributing to the code or maintaining it, should Reiser and Namesys withdraw from active development in the future.

Often, Reiser's initial response to these technical criticisms has been to make sweeping statements about the superiority of his team's methods and results, and to denounce reviewers of his code as unqualified. For example, in response to criticisms of his coding style, Reiser remarked, "Most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code," while he claims that the problem with having Reiser4 code reviewed by most other kernel developers is that "You can't really have code reviewed by persons less experienced and proven than those being reviewed." As several developers suggest, these reactions may slow down Reiser4's inclusion by making developers reluctant to become involved in the process.

If these were Reiser's only reactions, the controversy would remain minor. As Calleja says, other developers in the past have strained against the kernel's established policies and procedures, and "all of them failed or were just ignored." However, Reiser claims that his own experiences are symptomatic of more general problems. Linux kernel development, he suggests, would benefit from an influx of people who did things differently. "Researchers who stay in clumps are not the ones who become enriched from the ideas of many others," he says. Not only that, but Reiser and his supporters suggest that an insistence on conformity has caused leading filesystem programmers to withdraw from kernel development. The names raised include Donald Becker, Andre Hedrick, David Mazières, Jim Mostek, and Steve Lord. (Others have questioned the motivations for some of these withdrawals, or whether they have occurred at all. Jim Lord, for one, publicly denies ever leaving, and hopes to step up his activity again one day.)

Another problem, according to Reiser, is that standards are not being applied consistently. He compares what he perceives as the resistance to Reiser4 to the apparent fast-tracking of ext4, the recently announced successor to the widely used ext2 and ext3 filesystems. "The [ext4] code isn't even written, benchmarked, or tested yet," Reiser says, "and it is going into the kernel already so that its developers don't have to deal with maintaining patches separate from the tree." Some respond by pointing out that ext4 is a successor to technologies already in the kernel, and that its developers have a proven track record of following established procedures. But to Reiser, who is eager for the increased testing that would come with inclusion, the situation smacks of favoritism.

Reiser is also irked that conformity, not performance, is the gauge of whether Reiser4 is ready for the kernel. "If you offer twice the performance of others," he says, "you should be perceived as useful, and getting in should be easy for your filesystem. I am concerned here that what we have is a culture in which, if you benchmark, it is harder for you to get in because feelings get hurt. We are developing an anti-scientific culture, in which people think that they know what is right code without measuring it."

Reiser may score some philosophical points, but, in the end, he has little choice except to conform in order to realize his goal. While engaging in these policy debates, Reiser has also made considerable efforts to answer the criticisms about Reiser4's architectural and coding styles, until now, even his critics say that it is only a matter of time before Reiser4 is part of the kernel.

Personality and pride

For now, the arrival of that moment seems delayed by personality conflicts. Calleja specifically denies this assertion in his FAQ, calling it "shocking," and claiming the delay is due entirely to technical merits. Unfortunately, his inability to resist remarks such as "Hans Reiser has not helped a lot with his attitude" and "Hans is not the right person to deal with the rest of the kernel community" do more to support it than refute it.

The fact is, no one who has observed kernel development should be surprised that personality plays a role. As long ago as six years, ago, Jeff Garzik's guide to kernel development listed "You are being annoying" as a reason why a patch might be rejected. That remark may have been partly a joke, but much of the archives suggest that it has a strong foundation in the truth.

Reiser is hardly blameless. As some posters remark, Reiser is often undiplomatic and insulting. He describes Al Viro and Christoph Hellwig, for example, as "90% of the problem." Linus Torvalds remarks that Viro and Hellwig "aren't always easy to work with," so the conflicts are not wholly Reiser's fault, but he does not shy away from them, either.

Kernel development is a large responsibility, and pride undoubtedly plays a large role in everybody's reactions. Reiser, for instance, has spent years developing this filesystem, often through trial and error. Unsurprisingly, he is immensely proud of the result. "Reiser4 represents a huge pile of luck in design," he says. "I will most likely never get so lucky again in one of my design experiments." At the same time, he is also aware that the present technical superiority of his work will not last forever, and pleads, "Let me have my 15 minutes of technical relevance." Such considerations make impatience and bad manners understandable, if not excusable.

If anything, in the current exchange, both sides seem to be straining to stay polite. Perhaps they are tired of the issue. The trouble is, the efforts are not only inconsistent, but probably coming too late.

Summing up

Clearly, any answer to questions about Reiser4's status is complicated. But briefly -- and as neutrally as possible -- the reasons Reiser4 is not in the Linux kernel today can be summarized as claims that further testing are required and apparently genuine difficulties with integrating Reiser4 into the existing kernel structure, compounded by philosophical and personal differences. These difficulties may be unique to this situation, or may point to genuine problems in the conventions of kernel development. Either way, they cannot be ignored.

Whatever the case, the controversies surrounding Reiser4's inclusion are far from kernel developers' finest hour. Outsiders coming across the discussion could be forgiven for wondering sometimes whether they stumbled upon the Linux kernel mailing list or a group of script-kiddies who have just discovered Slashdot.

Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for NewsForge, and IT Manager's Journal.

Bruce Byfield is a computer journalist who writes regularly for

Share    Print    Comments   


on Reiser4 and the politics of the kernel

Note: Comments are owned by the poster. We are not responsible for their content.

I pity the fool!

Posted by: Anonymous Coward on August 05, 2006 12:42 AM
Umm, excuse me? They're fighting AGAIN? If memory serves this isn't the first time reiser and the kernel have clashed.*

*There really shouldn't be any fighting. The modular nature of Linux sees to that.


Hans ignorant

Posted by: Leandro Guimar„es Faria Corcete DUTRA on August 05, 2006 05:15 AM
Funny thing is that Reiser himself can be quite stupid in quite fundamental things. His famous whitepaper justifying his second-system filesystem dismisses the relational model of data management just like that, and then from that start he started building his castle — without ever having understood the fundamental, theoretical, proven concepts behind data models.

All his efforts are doomed, then, by a combination of ignorance and arrogance.


Re:Hans ignorant

Posted by: Anonymous Coward on August 05, 2006 11:47 AM
uh and how many filesystems have you created?


Sounds familiar

Posted by: Anonymous Coward on August 05, 2006 12:41 AM
I don't contribute code to the linux kernel for many of the reasons this article brings up. I've tried, and it is just too much trouble fighting over irrelevant issues, dealing with the politics and the lack of understanding (but ego-wise 'most knowledgeable') to get code accepted. I just ended up keeping the drivers I write, and changes to existing drivers as patches so I can apply them when a new kernel comes out.

Linux is a great operating system, and I use it almost exclusively. However, it could be much better if there was more of an inclusion attitude towards those who would like to contribute. I know there are many good developers who feel as I do that having to fight so hard to get inclusion is just not worth it.


Re:Sounds familiar

Posted by: Anonymous Coward on August 06, 2006 11:05 AM
Yes, they should just accept every bit of poorly written code without review... If they wanted to end up with a smoking pile of crap, that is.

The review process is painful, especially for first time submitters, and double that for people not used to having their code picked apart by other people. 90% of programmers believe themselves to be in the best 10%, and all that.

Someone may submit perfect code on its own, but that ends up being bad when viewed together with the rest of the kernel. The review process is mean to avoid bad code and code duplication, and the latter is especially problematic, since the most common scenario is for people to submit code which contains some pieces that could be made generic for the benefit of the rest of the kernel.

If you want to keep mantaining your changes outside of the kernel, then that's your problem. But it would be easier just figuring out what the kernel maintainers really want, instead of just assuming that they block submitters for fun.

BTW, you should try submitting code to any of the BSD's kernel, then you would really know what's "attitude"...


Kernel inclusion of code

Posted by: Anonymous Coward on August 05, 2006 01:59 AM
I also am not a kernel contributor. I wrote a paper describing the Organizational Communications structure of an open source project. IMHO if Hans Reiser wants his code included, he needs to read The Cathedral and Bazaar and like minded papers that Eric and others wrote. Since Hans is on the "outside" he needs to come in a humble way to the throne of kernel developers. If he cannot manage people well, he risks being disgarded (as is the current case). Attacking others will not gather them to his side. Diplomacy is the answer to such a huge investment of his time. My suggestion to Hans is to spend the time it takes to be nice to the Kernel developers because you are in your 11th hour, just a little more effort on your part will establish your legacy forever. Don't give up.


Re:Kernel inclusion of code

Posted by: Anonymous Coward on August 06, 2006 01:33 PM
I couldn't help but think, "that would be the Eric of cml2 (dis)fame?" : )

(google it if you don't know -- had to be one of the longest and nastiest include my software in the kernel fights I've ever seen...)


What ever happened to the 2.7 series kernel

Posted by: Anonymous Coward on August 05, 2006 04:28 AM
Used to be that once a new even-numbered kernel release came out, it was followed by an odd-numbered one.

Will there ever be a 2.7 (and eventually 2.8) kernel?


Re:What ever happened to the 2.7 series kernel

Posted by: Anonymous Coward on August 05, 2006 09:44 PM
This changed quite some time ago. Too many people were not using the odd-series kernels, and so nothing was getting tested (which was the purpose of the odd-series kernels in the first place).


Re:Bad fundaments

Posted by: Anonymous Coward on August 05, 2006 06:15 AM
I bet Newsforge would publish your article on the subject.


Re:Bad fundaments

Posted by: Administrator on August 05, 2006 10:47 AM
I bet I haven’t the time to write it, and it would be too pie-in-the-sky for Newsforge.


Linux kernel not unique

Posted by: Anonymous Coward on August 05, 2006 06:26 AM
I, too, find some of this behavior dismaying, but does anyone seriously believe that the messages on the lkml are any more harsh than e-mails flying around inside IBM, Sun, or Microsoft? The alternative to having these arguments in public is to have them in private, which doesn't seem like much of a solution for the most open software project on the planet.

Oh, and a 2.7 branch hasn't been opened because of the <a href="" title="">new kernel development model</a>.



Objective article

Posted by: Anonymous Coward on August 06, 2006 01:34 AM
I liked this article, it seemed to look at the issue from the point of views from both parts.

Important things like filesystem in a kernel, can take some time I guess, so I guess that it is normal that things like this happens, but it will eventually get solved, I believe.

BTW, isn't ZFS superior to everything?


Re:Objective article

Posted by: Anonymous Coward on August 06, 2006 11:08 AM
Hell no! If anything, XFS is superior than ZFS, but it has trouble with smaller files (performance-wise), which is its only major weak point.


Re:Bad fundaments

Posted by: Anonymous Coward on August 06, 2006 01:45 AM
I thoght relational systems worked poorly in certain types of situations. If reiser4 works in such a way then relational would be a detriment to it, not? This is assuming a few things ofcourse, but I would think it to be a valid point to consider. Relational in anycase has never been the silver arrow to solve all problems in the data world as far as I've understood from numerous articles, so I suppose real world situations don't always fulfill the theories premises well.


Re:Bad fundaments

Posted by: Anonymous Coward on August 06, 2006 11:12 AM
So you're chickening out. Really lame. Tell us, Mister Know-It-All, tell us what *you* really know. I bet you can't stand the scrutiny when your article is published.


Perhaps it isn't stable enough yet...

Posted by: Anonymous Coward on August 07, 2006 10:09 PM
At least from my experience, it wasn't a year ago. My company needed a file system that would scale to 2 Terabytes, and at the time we had been using Reiser3. We had a choice between Reiser4, JFS and XFS. We initially went with Reiser4, based on our good fortune with Reiser3. Initial tests went well, but once we entered a live scenario, multiple writes cased our system load to shoot into the teens and eventually freeze the system. When this happened several times a day, for several days in a row. We decided to cut our losses and transfer everything to JFS. Since then we have had zero file system issues and better performance than we ever had.

I know this isn't a benchmark, and is highly anecdotal, but it's why I would never user Reiser4 again.


Re:Perhaps it isn't stable enough yet...

Posted by: Anonymous Coward on February 24, 2007 07:10 AM
Well, maybe you should consider not using still-experimental file systems in a production environment -- and much less expecting them to work flawlessly.


A more technical article on

Posted by: Anonymous Coward on August 10, 2006 10:26 PM
A more technical article on reiser4 and possible inclusion is available from <a href="" title=""></a>.



Posted by: Anonymous Coward on February 07, 2007 06:16 PM
BENCHMARKS at <a href="" title=""><nobr>.<wbr></nobr> htm</a>


On the subject of contention

Posted by: Administrator on August 06, 2006 10:51 AM
The biggest issue people need to understand is that everything done in an environment like this (i.e. Open Source/Free Software) is moved by people who can ultimately be classified as Alpha Geeks. They are, by definition, strong and stubborn and self-righteous. This isn't a bad thing in that this drive is what gets things done. If we didn't have people like this there would never have been anything like Linux (or the *BSDs, for that mater). Strong personalities with an over abundance of knowledge and deep passion are the ones how move the mountain. It's also why you see many of these people burn out after a while. The key to dealing with this kind of system is to use the system rather than fight it. There's an old saying, "You can catch more flies with honey than you can with vinegar." That applies to kernel hackers as well.


Bad fundaments

Posted by: Administrator on August 05, 2006 04:55 AM

The real problem with Hans Reiser is that he is ignorant, and doesn’t know it. All his work is predicated on a misunderstanding of data theory, specially the relational data model. I understand he wants ReiserFS v4 to be a competitor to MS WinFS; but then he would need to have a better grounding in the relational model, which he dismisses in his papers.

It really frightens me how few people are aware of this problem or talk about it.



Posted by: Administrator on August 08, 2006 11:32 PM
New developments are not always better, but my company will try Reiser4.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya