Why Reiser4 is not in the Linux Kernel

hitguy

Contents
目录

Why Reiser4 is not in the Linux Kernel

Contents

Introduction

FAQ and Frequently Given Answers

Q1. "Why can't Reiser 4 be included as a experimental feature, Namesys, programmers will fix all the problems eventually!"

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

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

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

Introduction
"Why
Reiser4 Is Not Merged" is a widespread question around forums,
Slashdot, OSNews and wherever else Linux-related new appears on the
web. The flame-wars on this topic have gotten to the "mine is bigger
than yours" level. Hence, it's not easy to see where the real problem
lies. This document tries to be a sort of "official" point of view of
Linux community on this matter (but it doesn't means it's what everyone
thinks, either - Linux doesn't have a "central" opinion in many
matters)
It's shocking to read some people who believe that the main reason why Reiser4 is not in the
Vanilla Kernel
are "political disputes instead of technical merits". The circular
reasoning behind this seems to "Reiser4 is fast/it has plugins so it
can/should/must be included NOW. If you don't agree with me, then you
must have an irrational hatred against Reiser4, because I'm so
obviously right".
As usual, the world is not black or white, but grey (see a
Linus Torvalds post
discussing this and other issues). There is no "opposition force"
stopping Reiser4 from making it into the main Linux tree. Reiser4 needs
to attain a quality level high enough to be included. It's disturbing
to listen to people saying that Linux Maintainers did not want to
include a filesystems for political reasons. Linux is the kernel that
supports many filesystems from its own sources. Linux even includes
(being fair) a lot filesystems people consider worthless. Linux
supports filesystems that are rarely used. e.g. 9p, BeFS, BFS, minixfs,
ADFS, AFFS, EFS, HPFS, UFS, VXFS, qnx4fs, sysvfs, ncpfs, codafs. There
are several relevant filesystem choices as well: ext3, XFS, JFS, JFFS
and reiser3. Many people have chosen these and are happy with them.
Does that really sounds like a kernel that would not merge a filesystem
for political reasons? If anything, Linux looks more like a filesystem
bitch.
Since
the initial request to get Reiser4 merged, it hasn't been declared
ready by people who know. "It works for me on my PC" isn't exactly the
way engineers should make decisions. Of course, nobody expects Reiser4
to be bug-free before getting merged. It must meet with the design
tenets and quality specifications laid out by the existing maintainers.
Writing a filesystem from scratch is not easy, and Reiser4 in
particular is attempting to break a lot of new ground, so it's even
harder for them. It is expected that it takes a lot of time and effort
to finish it, and reiser 4 has consistently moved forward since the
first discussions of merging years ago thanks to all the hard work. As
for today, thanks to all the work done by the Namesys people, Reiser4
is
growing near to inclusion
in the main tree and hopefully it won't get take too many time until
reiser 4 is merged. Namesys has been working on this question for
two-plus years, so you can imagine what the state of readiness was when
it was initially submitted, but all this work is also a good sign, in
every way this points to the future success of Reiser4. You can bet
that
ZFS
has been working for a long time before being included in
OpenSolaris
, and that it took a lot of time to polish it, just like it happens with every big software project.
So
that's it: Things need to have a decent shape before being included,
and Reiser4 is not there yet (NOTICE, however, that people needs to
take so much care because Linux is under a "stable" stage). Many people
in this process have taken
FUD
against Linux to religious zealotry. This is not the first time for
difficult issues surrounding developers, maintainers and the Kernel.
Egos this large sometimes have disputes. Disputes like Reiser4, and XFS
before it, and the IDE layer in the 2.4.x days, don't always create
this situation. For instance, take
OCFS2
and
GFS
. These are clustering filesystems, OCFS2 made by
Oracle
and GFS comes from
RedHat
.
Both companies/groups have submitted their filesystems for inclusion,
but only OCFS2 is in today. GFS still needs some more work, but once
all the
issues are settled down
it will be included, just like Reiser4 (hopefully) will.
Finally,
before it can be merged Reiser4 code needs a review and sign-off by
some kernel developer who knows how a file system must behave. This is
an evolving standard and practice. It heavily affected XFS, bringing
tears and whining from a number of people. Many of the same arguments
for inclusion used on behalf Reiser4 were previously used for XFS.
Linux Devs and Maintainers wanted to see certain qualities and changes
in the XFS code. The XFS team at SGI plodded along, and after much ado,
Christoph Hellwig consented to perform a final review. Some developers
grew offended, some people got angry and caustic. There are not a of
these people who are trusted to do this work. There are even less who
are willing to do it. By the time that Christoph took up the work, it
was make or break. None of the other Linux Devs were willing. Some even
indicated that the job was all but impossible.
By
the same token, there were Linux Devs and maintainers who did early
reviews of Reiser4 and were verbally abused by Hans Reiser (see FAQ
#3). Lots of people have weighed-in for those messes. Some Maintainers
are unwilling to work with Reiser4 anymore. They don't oppose the
filesystem. However, someone else must review and sign off on it. Egos
aside, this just makes the process slow.
FAQ and Frequently Given Answers

Q1. "Why can't Reiser 4 be included as a experimental feature, Namesys, programmers will fix all the problems eventually!"
Nobody
expects Reiser4 to be bug-free and the day it gets merged it'll
probably be marked as "experimental". But there are some important
issues that a piece of code (be it a filesystem or a driver) needs to
fix before getting included, like for example playing well with the
rest of the linux subsystems. Namesys developers have been fixing some
of those problems for years, so it's not that it has been a error not
having inclued Reiser 4 some years ago. 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
during a stable development phase (2.6). Linux is already being
criticized a lot for merging new features during this stable phase and
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 once you start using it, and that it won't be
a nightmare to fix it.
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
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,
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 (they listen
to their users). 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, because the kernel
has to care about long-term maintainance.
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 with his attitude to solve them. 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
question #1 above
, Hans Reiser has been claiming that Reiser4 is ready
for 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 been using it for years and it rocks, how can't it be ready?"
You are not a kernel programmer, aren't you?
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/48817/showart_414269.html