"Why Reiser 4 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's just not possible to know what the real problem is. This document tries to make clear the "official" POV of Linux developers is on this matter.

It's shocking to see some people writting that the main reason why reiser4 is not in is "politics instead of technical merits". The wonder reasoning behind this reasoning is "it's fast/it has plugins so it can be included NOW. If you don't agree with me you've an irrational hatred against reiser4, because I'm obviously right".

BR As usually, the world is not black or white, but grey. Nobody oposes to getting reiser4 into the main linux tree, once it gets a quality level good enougth to be included. It's kind of shocking to listen people say that Linux doesn't want to include a filesystems for political reasons, being Linux the operative system that more filesystems supports from its own sources. Linux even includes (being fair) a lot of worthless filesystems that nobody cares about. Linux supports filesystems that people rarely uses, 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 everybody is happy with them. Nobody is planning to kill them.

BR Does that really sounds like a operative system that would not merge a filesystem for political reasons? If anything, Linux looks more like a filesystem bitch.

BR In all the months that people has tried to get reiser 4 in, reiser4 just was not ready. "It works for me in my little PC" isn't exactly the way engineers should take decisions. Nobody sane expects reiser4 to be bug-free before getting merged, but before getting it in it must have a reasonable level of quality, specially design issues. Writting a filesystem from scratch is not easy at all (specially if it's so big and complex and it features new "paradigms" that are not very common, like it happens with reiser4). The reiser 4 guys chose to do that and it's comprehensible that it takes a lot of time and efforts: 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 [ more near] of being included in the main tree (it may be already for 2.6.19, who knows)

So thats it: Things need to have a decent shape before being included, and reiser 4 was not, so people can't understand (or maybe they understand it too easily) all those FUDs against linux because of this matter. If it's not ready, they will be rejected. Just for comparison, take OCFS2 and GFS. They're clustering filesystems, OCFS2 is made by Oracle and GFS cames from Red Hat (who bought it to Sixtina). Both filesystems have submitted their filesystems for inclusion, but only OCFS2 is in (since 2.6.16 and after lots of reviews). GFS apparently needs some work, but once all the [ issues are settled down] it'll be included, just like reiser4.

Furthermore, in order to ensure that it doesn't have any major problems it needs to be reviewed by some kernel developer guru that knows how a FS must behave. There're not a lot of them, and the ones that have tried to review it have got verbally abused by Hans Reiser so hard that some of them just don't want to review it again. They don't oppose to get reiser 4 merged if someone else reviews and approves it, they just are not willing to be the ones that do that job, and since reviews are done by volunteers its harder to find one that is willing and has the time to review it. All this just makes things go slower.

BTW, does some people still remembers how hard 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 changed XFS by reiser 4. People who still ignores the same issues that they ignored at that time and that surprisingly aren't linux maintainers and don't have to waste some hours of their free time maintaining buggy code.

BR Now, a small FAQ:

"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 reiser 4 to be bug-free, but there're some important issues that need to be fixed, the problems is that reiser 4 is still working in 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 reason, etc. Every piece of code submitted needs to have some quality - requesting developers to fix severe issues before getting it into the main tree helps to have better code. If you ask people people to fix those issues "in the future", they'll be lazy and there'll be critical issues around all the time - this has happened in Linux in the past. Quality is important, specially under a stable development phase. Linux is already being critized 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 what Reiser 4 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.

"But by not including Reiser 4, you aren't allowing Reiser 4 to be tested and it will never get into a decent shape!"

Wrong. Read question #1. And we live in a opensource land. Nobody stops people from testing reiser 4 now, or including it in the next ubuntu/fedora/whatever release. In fact, when reiser 4 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 in one or two distros before merging it. 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 depends on kernel developers - if a feature gets included in several distros it means that people wants it and that you can check its quality in bugzillas. In the particular case of Reiser 4, Andrew Morton has even [ said] that Uptake by a vendor or two would be good. If you want to help reiser 4 to get developed faster, bugzilla your particular distro asking to include it. Distros 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.

"Kernel developers hate Hans Reiser, that's why they haven't merged Reiser 4"

Well, no and yes. As said, they're the technical issues what are stopping it, not anything else. Now, it's true that Hans Reiser hasn't helped a lot to solve those issues. Telling linux developers that reiser 4 is stable enought and that it should get merged because they'll fix all the issues in the future doesn't helps a lot (see FAQ 1, he has been saying that reiser 4 is ready since years). It doesn't helps either to mention how much VFS maintainers hate you and how much smarter your coders are compared with them. It doesn't help to say how closed-minded they're because they're asking reiser4 to disable some advanced Reiser 4 features (features that happen to clash with the VFS and that reiser 4 has ended up disabling anyway). It doesn't help to mention repeatedly how Linux is doomed against winfs because they're not allowing reiser 4 to be merged today - despite that other people is free to disagree with Hans' predictions - and how evil people is for asking him to fix bugs instead of helping him to do the Right Thing. It doesn't really helps to suggest kernel developers that they should replace the Linux's VFS with Reiser 4's plugin layer because reiser 4 is faster than ext3.

Attacking people when they disagree with you is not the right way of talking into a open source community, neither it helps to try to convince kernel developers to merge reiser 4 talking to them with marketing speak. That however won't stop reiser 4 from getting into the kernel, but it certainly does things more difficult. Some people has said that Hans is not the right people 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, maybe you're right".

"I've using for years and it rocks, how can't it be ready?"

You are not a programmer, aren't you?

KernelNewbies: WhyReiser4IsNotIn (last edited 2006-07-17 11:50:54 by diegocalleja)