Why reiser4 is not in the Linux Kernel
"Why reiser4 is not in" is a widespread question around forums, Slashdot, OSNews, etc. when a linux-related new appears in the web. The flamewars on this topic have got to the "mine is bigger than yours" level and hence it is just not possible to know what the real problem is. This document tries to make clear the "official" point of view of Linux developers is on this matter.
It is shocking to see some people writing that the main reason why reiser4 is not in were "politics instead of technical merits". The wonder reasoning behind this reasoning is "it is fast/it has plugins so it can be included NOW. If you don't agree with me you have got an irrational hatred against reiser4, because I'm obviously right".
As usual, the world is not black or white, but grey. Nobody opposes to getting reiser4 into the main linux tree, once it attains a quality level good enough to be included. It is shocking to listen to people saying that Linux did not want to include a filesystems for political reasons, because Linux is the operating system that supports many filesystems from its own sources. Linux even includes (being fair) a lot of worthless filesystems that nobody cares about. Linux supports filesystems that people rarely use, like 9p, BeFS, BFS, minixfs, ADFS, AFFS, EFS, HPFS, UFS, VXFS, qnx4fs, sysvfs, ncpfs, codafs. As for revelant filesystems others than ext3, Linux does support XFS, JFS, JFFS, reiser3, and many people are happy with at least one of them. Nobody is planning to remove them.
Does that really sounds like a operating system that would not merge a filesystem for political reasons? If anything, Linux looks more like a filesystem bitch.
In all the months that people have tried to get reiser4 in, it just was not ready. "It works for me in my little PC" isn't exactly the way engineers should make decisions. Of course, nobody expects reiser4 to be bug-free before getting merged, but before getting it in, it must have a reasonable level of quality, especially with respect to design issues. Writing a filesystem from scratch is not easy at all (particularly if it's so big and complex and it features new "paradigms" that are not very common, as the case is with reiser4). The reiser4 authors chose that approach nonetheless and it is comprehensible that it takes a lot of time and effort: they have been working on fixing those issues for years. As for today, thanks to all the work done by the reiser people reiser4 is [http://marc.theaimsgroup.com/?l=linux-kernel&m=115265566213465&w=2 more near to being included] in the main tree. It may be already for 2.6.19, but remember that reiser 4 was submitted for inclusion for first time YEARS ago. Reiser 4 people is still working on issues to get it included, so you can imagine what the state was the first time it was submitted and in all those years. It's not surprising: Reiser 4 is a complex filesystem, and it's taking reiser people some years to finish it. Writing a filesystem is a very complex task. You can bet that ZFS has been working for a long time before being included in opensolaris.
So that's it: Things need to have a decent shape before being included, and reiser4 was not, so people cannot understand (or maybe they understand it too easily) all those FUD against linux because of this matter. If it's not ready, it will be rejected. Just for comparison, take OCFS2 and GFS. These are clustering filesystems, OCFS2 made by Oracle and GFS comes from Red Hat (who bought it from Sixtina). Both filesystems have submitted their filesystems for inclusion, but only OCFS2 is in today (since 2.6.16 and after lots of review-and-change cycles). GFS apparently needs some more work, but once all the [http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=1&s=GFS&q=b issues are settled down] it will be included, just like reiser4.
Furthermore, in order to ensure that reiser4 does not have any major problems, it needs to be reviewed by some kernel developer who knows how a file system must behave. There are not a lot of these people, and the ones that have tried to review it have gotten verbally abused by Hans Reiser so hard that some of them just don't want to review his code again. They don't oppose to get reiser4 merged if someone else reviews it and approves of it, they just are not willing to be the ones to do that job, and since reviews are done by volunteers it's harder to find one who is willing and has the time to review it. All this just makes things go slower.
BTW, do some people still remember how hard it was to get XFS into the main tree? Try to remember: some people spent countless threads saying exactly what they're saying now. "Linux developers don't want to merge XFS because they only like ext3, linux developers hate XFS, linux developers don't care about technical merits", blah blah blah. They're the same people, they just switched from XFS to reiser4. People who still ignore the same issues that they ignored at that time and who surprisingly aren't linux maintainers and don't have to waste some hours of their free time maintaining buggy code.
FAQ and Frequently Given Answers
Q1. "But just include it as experimental code regardless of everything, reiser programmers will fix all the problems eventually!"
Well, no and yes. As said, nobody expects reiser4 to be bug-free, but there are some important issues that need to be fixed. The problem is that the reiser developer team is still working on the important ones. Some of the issues fixed in the past included severe design issues, BTW. Others are about being well integrated with Linux: duplication of kernel's own functionality for no good reason, etc. Every piece of code submitted needs to meet quality standards - requesting developers to fix severe issues before getting it into the main tree helps to have better code. If you ask people to fix those issues "in the future", they may be lazy and so there may be critical issues around all the time - this has happened with Linux in the past. Quality is important, especially in a stable development phase. Linux is already being criticized a lot for merging new features during this stable phase - that criticism happens with the current quality control. Imagine what would happen if Linux started to merge things without caring a bit about what gets merged. Also, consider how important reiser4 is. It's a filesystem, once it gets included in the kernel many people will use it and will depend on it (your disk format is reiser4): Linux needs to ensure that things don't blow up everything.
Q2. "But by not including Reiser4, you aren't allowing reiser4 to be tested and it will never get into a decent shape!"
Wrong. Read [#includeexp question #1 above]. And we live in a Open Source land. Nobody stops people from testing reiser4 now, or including it in the next Ubuntu/Fedora/whatever release. In fact, when reiser4 is included it will be merged as "experimental" code, and there's no real difference between that and patching and compiling their own kernels, it's just a psychological thing: people will think it's more stable when it's included even if marked as experimental, for no real reason.
BTW, in the kernel world it's a quite common practice to get a feature into one or two distros before merging it into the baseline kernel. Being included in distros is valued a lot by linux maintainers, because it gets a lot of real-world testing and bug fixing. And that's something that doesn't really depend on kernel developers - if a feature gets included in several distros, that means that people want it and that you can check its quality in the distributor's bug tracking systems. In the particular case of reiser4, [http://kerneltrap.org/node/6681 Andrew Morton has even said] that Uptake by a vendor or two would be good. If you want to help reiser4 to get developed faster, bug your particular Linux distribution and ask them to include it. Distributions can allow to merge unstable code (and they do that with several drivers that are not in mainline, like ndiswrapper), but it's not so easy for the kernel.
Q3. "Kernel developers hate Hans Reiser, that's why they haven't merged Reiser 4"
Well, no and yes. As said, there are the technical issues that are stopping it, not anything else. Now, it is true that Hans Reiser has not helped a lot to solve those issues. Telling linux developers that reiser4 is stable enough and that it should get merged because they would fix all the issues later does not help a lot (see [#includeexp question #1 above], Reiser has been claiming that reiser4 is ready since years). It doesn't help either to mention how much VFS maintainers hate you and how much smarter your coders are compared to them. It doesn't help to say how closed-minded they are because they're asking reiser4 to disable some advanced reiser4 features (features that happen to clash with the VFS and that reiser4 has ended up disabling anyway). It doesn't help to mention repeatedly how Linux is doomed against winfs because they're not allowing reiser4 to be merged today - despite that other people are free to disagree with Hans's predictions - and how evil people are for asking him to fix bugs instead of helping him to do "The Right Thing". It doesn't really help to suggest to kernel developers that they should replace the Linux's VFS with reiser4's plugin layer just because reiser4 is faster than ext3.
Attacking people when they disagree with you is not the right way of talking within a Open Source community (or any community for that matter), neither is it helpful to try to convince kernel developers to merge reiser4 talking to them with marketing speak. That however will not stop reiser4 from getting into the kernel, but it certainly makes things more difficult. Some people have said that Hans is not the right person to deal with the rest of the kernel community. I think that almost everyone agrees. Reiser4 programmers are certainly more friendly, and like most of normal programmers they focus on technical discussions and they know to say "OK, you're Linux developers, so you probably know better than me how a linux filesystem must be written".
Q4. "I've using for years and it rocks, how can't it be ready?"
You are not a kernel programmer, aren't you?