|
Size: 6815
Comment: create
|
Size: 11226
Comment: use marc.info for URL
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| "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. | #language en = Why Reiser4 is not in the Linux Kernel = /!\ The neutrality of this article is disputed. Read [[http://lkml.org/lkml/2006/7/21/109|Hans Reiser's view]] too. /!\ |
| Line 3: | Line 5: |
| 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 that you've an irrational hatred against reiser4". | = Contents = <<TableOfContents>> |
| Line 5: | Line 8: |
| = Introduction = "Why is Reiser4 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 that doesn't mean it's what everyone thinks, Linux doesn't have a "central" opinion) |
|
| Line 6: | Line 11: |
| 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, including (being fair) a lot of worthless ones 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. | It's shocking to read that some people believe the main reason why Reiser4 is not in the [[http://en.wikipedia.org/wiki/Linux_kernel#Versions|Vanilla Kernel]] are "political disputes instead of technical merits". The reasoning behind this seems to be "Reiser4 is fast/it has plug-ins 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". |
| Line 8: | Line 13: |
| As usual, the world is not black or white, but grey (see a [[http://lkml.org/lkml/2006/7/28/180|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 do 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 major filesystem choices as well: ext3, XFS, JFS, JFFS and reiser3. Many people are happy with these choices. 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. | |
| Line 9: | Line 15: |
| Does that really sounds like a operative system that would not merge a filesystem for political reasons? | 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 they have 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 [[http://marc.info/?l=Linux-kernel&m=115265566213465&w=2|growing near to inclusion]] in the main tree and hopefully it won't take too much time until Reiser4 IS merged. Namesys has been working on this question for two-plus years, so you can imagine what the state of the code 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 [[http://www.opensolaris.org/os/community/zfs/|ZFS]] had been working for a long time before being included in [[http://www.opensolaris.org/os/|OpenSolaris]], and that it took a lot of time to polish it, just like it happens with every big software project. |
| Line 11: | Line 17: |
| So that's it: Things need to have a decent shape before being included, and Reiser4 is not there yet (Note that people need to take extra care since Linux is supposedly "stable"). Many people in this process have taken [[http://en.wikipedia.org/wiki/FUD|FUD]] against Linux to religious zealotry. This is not the first time difficult issues surrounding developers, maintainers and the Kernel have arisen. 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 [[http://oss.oracle.com/projects/ocfs2/|OCFS2]] and [[http://www.redhat.com/software/rha/gfs/|GFS]]. These are clustering filesystems, OCFS2 made by [[http://www.oracle.com/index.html|Oracle]] and GFS comes from [[http://www.redhat.com|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 [[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 (hopefully) will. | |
| Line 12: | Line 19: |
| In all the months that people has tried to get reiser 4 in, reiser4 just was not ready. Nobody sane expects reiser4 to be bug-free, but before getting it in it must have a decent shape. 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 reiser4 does). The reiser 4 guys chose to do that and it's comprehensible that it takes a lot of efforts, they have been working on fixing those issues for years, to the point that reiser4 is [http://marc.theaimsgroup.com/?l=linux-kernel&m=115265566213465&w=2 more near] of being included in the main tree (it may be already for 2.6.19, who knows) | 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 lot of 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. |
| Line 14: | Line 21: |
| 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. | |
| Line 15: | Line 23: |
| So thats it: Things need to have a decent shape before being included, and reiser 4 was not, so people can't understand all those FUDs against linux because of this question (or maybe it's too easy too understand). 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 [http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=1&s=GFS&q=b issues are settled down] it'll be included, just like reiser4. Now, a small FAQ: | = FAQ and Frequently Given Answers = <<Anchor(includeexp)>> |
| Line 17: | Line 26: |
| == Q1. "Why can't Reiser4 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 - getting developers to fix severe issues before it makes it into the main tree helps to maintain better code. If you ask people to fix those issues "in the future", they may be lazy and so there may be critical issues laying vestigial in the code - this has happened with Linux in the past. Quality is important. Consider how important Reiser4 is. It's a filesystem, and thus once it gets included in the kernel many people will use it and their data will depend on it. Linux needs to ensure that things don't blow up once you start using it. |
|
| Line 18: | Line 29: |
| == 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. |
|
| Line 19: | Line 32: |
| ==== "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. 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. |
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 (they listen to their users). Distributions can allow the merging of 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 maintenance. |
| Line 22: | Line 34: |
| == 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 solving the issues. Telling Linux developers that Reiser4 is stable enough and that it should get merged because they would fix all the issues later doesn't help a lot (see [[#includeexp|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 the fact 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. |
|
| Line 23: | Line 37: |
| ==== "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. 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. |
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". |
| Line 26: | Line 39: |
| 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 it will be more stable. In the particular case of Reiser 4, Andrew Morton has even [http://kerneltrap.org/node/6681 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. | == Q4. "I've been using it for years and it rocks, how can't it be ready?" == You are not a kernel programmer, are you? |
| Line 28: | Line 42: |
==== "Kernel developers hate Hans Reiser, that's why they haven't merged Reiser 4" ==== Well, no and yes. As said, they're technical issues what stop it. Now, it's true that Hans Reiser hasn't helped a lot. 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, how closed-minded they're for asking disable some advanced Reiser 4 features (features that happen to clash with the VFS), or how Linux is doomed because of the ignorance of their developers becayse they're not allowing reiser 4 to be merged today. It doesn't really helps to tell kernel developers that because reiser 4 is faster than ext3 they should replace the Linux's VFS with Reiser 4's plugin layer. 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 like a manager. That however won't stop reiser 4 from getting into the kernel, but it certainly does things more difficult as people gets distracted into the real goal: improve reiser 4. |
---- CategoryDocs |
Why Reiser4 is not in the Linux Kernel
![/!\](/moin_static1911/memodump/img/alert.png "/!\"){kind=small}
The neutrality of this article is disputed. Read Hans Reiser's view too.
Contents
Contents
- Why Reiser4 is not in the Linux Kernel
- Contents
- Introduction
-
FAQ and Frequently Given Answers
- Q1. "Why can't Reiser4 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 is Reiser4 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 that doesn't mean it's what everyone thinks, Linux doesn't have a "central" opinion)
It's shocking to read that some people believe the main reason why Reiser4 is not in the Vanilla Kernel are "political disputes instead of technical merits". The reasoning behind this seems to be "Reiser4 is fast/it has plug-ins 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 do 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 major filesystem choices as well: ext3, XFS, JFS, JFFS and reiser3. Many people are happy with these choices. 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 they have 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 take too much time until Reiser4 IS merged. Namesys has been working on this question for two-plus years, so you can imagine what the state of the code 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 had 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 (Note that people need to take extra care since Linux is supposedly "stable"). Many people in this process have taken FUD against Linux to religious zealotry. This is not the first time difficult issues surrounding developers, maintainers and the Kernel have arisen. 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 lot of 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 Reiser4 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 - getting developers to fix severe issues before it makes it into the main tree helps to maintain better code. If you ask people to fix those issues "in the future", they may be lazy and so there may be critical issues laying vestigial in the code - this has happened with Linux in the past. Quality is important. Consider how important Reiser4 is. It's a filesystem, and thus once it gets included in the kernel many people will use it and their data will depend on it. Linux needs to ensure that things don't blow up once you start using 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 the merging of 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 maintenance.
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 solving the issues. Telling Linux developers that Reiser4 is stable enough and that it should get merged because they would fix all the issues later doesn't 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 the fact 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, are you?