The question of if and when Reiser4 will be merged into the mainline Linux kernel has been an on-going debate for a couple of years [story [1]]. The filesystem was described as being "fairly stable for average users" by Hans Reiser [interview [2]] over two years ago, in March of 2004 [story [3]]. It has been merged into Andrew Morton [interview [4]]'s -mm kernel [story [5]], though issues such as Reiser4 plugins [story [6]] and coding style [story [7]] caused lengthy discussions last year. Two recent threads on the lkml [8] raised the question again, asking at a non-technical level why Reiser 4 has not been included in the Linux kernel. Some have offered theories that Reiser4 is being blocked for political reasons, others because of concerns that once Reiser4 is included Namesys might forget it and move onto another filesystem. Responses to these theories point out that in reality there are technical issues that must be resolved before the filesystem will be merged, and that much progress has been made toward this end. Additional discussion can be found on a relevant recently created kernel newbies wiki page [9].
Hans Reiser posted a "short term task list for Reiser4" to address the remaining technical issues. The todo list included getting batch_write merged into the -mm kernel [story [10]], getting read optimization code merged into the -mm kernel, documenting everything in the Namesys wiki [11], exploring and addressing reports of system pauses when using Reiser4, a complete review of the crypt-compress code, a large effort in optimizing fsync, a review of installation instructions, and a review of the kernel documentation. Hans explains, "unfortunately, our code stability is going to decrease for a bit due to all these changes to the read and write code --- no way to cure that but passage of time. On the other hand, our CPU usage went way down. Reiser4's only performance weakness now is fsync. Once the crypt-compress code is ready, we will release Reiser4.1-beta (with plugins, releasing a beta means telling users that if they mount -o reiser4.1-beta then cryptcompress will be their default plugin, and if they don't, then they are using Reiser4.0 still). Doubling our performance and halving our disk usage is going to be fun."
From: "ivo welch" [email blocked] To: linux-kernel Subject: reiserFS? Date: Sun, 16 Jul 2006 08:45:58 -0400 dear linux geeks: may I ask why the "new" (many years old) reiser filesystem is not making it into the kernel? it does seem to have some advantages, if nothing else at least over the old reiser v3. sincerely, /ivo welch (please cc me personally. I am not a linux geek accdg to the lkml faq, but just an end user.)
From: Matthias Andree <matthias.andree@gmx.de> Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 15:50:38 +0200 On Sun, 16 Jul 2006, ivo welch wrote: > dear linux geeks: may I ask why the "new" (many years old) reiser > filesystem is not making it into the kernel? it does seem to have > some advantages, if nothing else at least over the old reiser v3. Why would anyone want ReiserFS in the kernel that is discontinued by its developers when it's just started to become stabile and useful, with bugs (hashing) remaining, as happened with 3.6? Who is going to make guarantees this won't happen again with reiser4? Besides that, there had been technical discrepancies that prevented reiser4 inclusion into the baseline kernel when it was suggested, search the archives for details. There's ext3, you can set the dir_index option (either for mke2fs, or afterwards with tune2fs, then unmount and run e2fsck -fD) and you're set. -- Matthias Andree
From: Lexington Luthor <Lexington.Luthor@gmail.com> Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 16:29:24 +0100 Matthias Andree wrote: > Why would anyone want ReiserFS in the kernel that is discontinued by its > developers when it's just started to become stabile and useful, with > bugs (hashing) remaining, as happened with 3.6? Who is going to make > guarantees this won't happen again with reiser4? I looked at the reiser4 patch, and it does very little outside of the fs/reiser4 directory. If it is no longer supported by namesys, why can't it just be removed from the kernel like all the other bits that are obsoleted? I am just saddened that kernel decisions are motivated by politics and a personal dislike of Hans Reiser rather than technical merit. :( > There's ext3, you can set the dir_index option (either for mke2fs, or > afterwards with tune2fs, then unmount and run e2fsck -fD) and you're set. I am not arguing for the inclusion of reiser4 in the kernel, but you should know it has its uses. There are very many things that reiser4 can do that will make ext3 blow up. It simply the best filesystem for many kinds of usage patterns. Regards, LL
From: grundig [email blocked] Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 18:55:30 +0200 (added by [email blocked]) El Sun, 16 Jul 2006 16:29:24 +0100, Lexington Luthor <Lexington.Luthor@gmail.com> escribió: > I am just saddened that kernel decisions are motivated by politics and a > personal dislike of Hans Reiser rather than technical merit. :( You (and every reiser4 fan that FUDs against linux developers just because he can't understand why reiser4 still is not in) are seriously missing the point. Nobody is oppossing that reiser4 gets into the main linux tree. Let me remember you that Linux has already merged quite a lot of filesystems, including a lot of them that don't even matter in the real world (BeFS, minix, ADFS, AFFS, EFS, VXFS, qnx4fs, sysvfs, ncpfs, codafs. Let me also remember you that we have had other relevant filesystems for year (reiser3, XFS, JFS), and everybody is ok with them, nobody is planning to kill anyone. With this short panoramic view of Linux I find shocking that people dares even to _suggest_ that linux don't want to include a filesystem for "political reasons". Just to point you how wrong you are, compare OCFS2 and GFS. Both of them are clustering filesystems, being OCFS from Oracle and GFS from Redhat. _Both_ filesystems have been asked to be included in the main tree. As for today, only OCFS2 is in (since 2.6.16, after several reviews and after fixing their code like everyone else). GFS still isn't in and seems to need work, but you won't see to the GFS technical leader tell everybody (like Hans has done here) that Linux politics don't allow GFS to go in. Instead of wining, they just go back to work on their issues.
From: Arjan van de Ven [email blocked] Subject: Re: reiserFS? Date: Mon, 17 Jul 2006 11:23:02 +0200 > With this short panoramic view of Linux I find shocking that people > dares even to _suggest_ that linux don't want to include a filesystem > for "political reasons". that's just their way of doing politics; they think that by using that sort of psychological warfare the code gets merged without review rather than with ... and sometimes it even works unfortunately.
From: Matthias Andree <matthias.andree@gmx.de> Subject: Re: reiserFS? Date: Mon, 17 Jul 2006 16:56:04 +0200 On Sun, 16 Jul 2006, Lexington Luthor wrote: > Matthias Andree wrote: > >Why would anyone want ReiserFS in the kernel that is discontinued by its > >developers when it's just started to become stabile and useful, with > >bugs (hashing) remaining, as happened with 3.6? Who is going to make > >guarantees this won't happen again with reiser4? > > I looked at the reiser4 patch, and it does very little outside of the > fs/reiser4 directory. If it is no longer supported by namesys, why can't > it just be removed from the kernel like all the other bits that are > obsoleted? People (including you) would scream blue murder if their file system were going away. The same would happen if it just didn't work for them. Somebody, however skilled they may be, just trying out a patch and finding it works for them is certainly not sufficient reason to judge if a product is of adequate quality. The code was reviewed, found to contain major misdesigns, and the maintainers refused to fix those, and that's it. > I am just saddened that kernel decisions are motivated by politics and a > personal dislike of Hans Reiser rather than technical merit. :( If you had understood my postings, it had been clear to you that there have been technical reasons that blocked the inclusion, and there have additionally been precedences of such misconduct, or maintainers declaring the system stable when in fact it was years (literally) from that. I respect namesys for the efforts they made in getting 3.6 and the toolchain workable, but some issues remain that some people never run into, are showstoppers for others, and at that point where minor polishing was due, namesys moved on to reiser4, dropping 3.6 support - and that was a decision that made me phase out reiserfs 3.6, and I'm certainly not looking into reiser4 until 2 years after a first major distro (that's currently Debian, Ubuntu, Fedora, Opensuse, Mandrake) ships it as the default root and user FS. > >There's ext3, you can set the dir_index option (either for mke2fs, or > >afterwards with tune2fs, then unmount and run e2fsck -fD) and you're set. > > I am not arguing for the inclusion of reiser4 in the kernel, but you > should know it has its uses. There are very many things that reiser4 can > do that will make ext3 blow up. It simply the best filesystem for many > kinds of usage patterns. Apparently, kernel coding standard applicability doesn't fall into the usage patterns you're referring to. SCNR. I haven't heard the other side, but if you're going to contribute to some project you MUST please its maintainers - life's bad... -- Matthias Andree
From: Xavier Roche <roche+kml2@exalead.com> Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 18:16:31 +0200 > It simply the best filesystem for many kinds of usage patterns. The most frightening too. Reiserfs might be suitable for very specific appliactions, but to use it in production machine, you need to have some guts. My last reiserfs partition was blown up two days ago, because of a bad sector, plus a fatal oops, looping endlessly. This was the second time, and the last one, as none of my ext3 filesystems *ever* had similar problems, despite numerous other bad sector issues. Not mentionning the funny "recovery" tool, which generally finishes to trash your data. Jul 14 23:35:29 linux kernel: hdh: dma_intr: status=0x51 { DriveReady SeekComplete Error } Jul 14 23:35:29 linux kernel: hdh: dma_intr: error=0x40 { UncorrectableError }, LBAsect=12458384, sector=12458383 Jul 14 23:35:29 linux kernel: ide: failed opcode was: unknown Jul 14 23:35:29 linux kernel: end_request: I/O error, dev hdh, sector 12458383 Jul 14 23:35:29 linux kernel: ------------[ cut here ]------------ Jul 14 23:35:29 linux kernel: kernel BUG at fs/reiserfs/file.c:620! .. Jul 14 23:35:29 linux kernel: <0>Fatal exception: panic in 5 seconds The funny part is that 14 july is the french's fireworks day, generally launched around midnight.
From: Christian Trefzer [email blocked] Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 18:28:31 +0200 On Sun, Jul 16, 2006 at 06:16:31PM +0200, Xavier Roche wrote: > > It simply the best filesystem for many kinds of usage patterns. > > The most frightening too. Reiserfs might be suitable for very specific > appliactions, but to use it in production machine, you need to have > some guts. > > My last reiserfs partition was blown up two days ago, because of a bad > sector, plus a fatal oops, looping endlessly. This was the second > time, and the last one, as none of my ext3 filesystems *ever* had > similar problems, despite numerous other bad sector issues. Not > mentionning the funny "recovery" tool, which generally finishes to > trash your data. I don't quite understand. You are supposed to dd_rescue the whole block device to a working drive and use fsck on the copy. Whatever is lost in the process must of course be restored from a recent backup. But, as a friend of mine put it recently, people don't need backup, they only need restore ; ) fsck on a faulty drive might cause even more damage - how do you know that other areas of the device are OK? I also oppose the ReiserFS-v3.x design philosophy regarding faulty storage layer, but in any case where your _live_ data is valuable and uptime counts, you _really_should_ use a RAID of some sort. Kind regards, uziel PS: Your mail was line-wrapped really bad, you might want to look into that.
From: Theodore Tso [email blocked] Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 12:56:48 -0400 On Sun, Jul 16, 2006 at 06:28:31PM +0200, Christian Trefzer wrote: > I don't quite understand. You are supposed to dd_rescue the whole block > device to a working drive and use fsck on the copy. Whatever is lost in > the process must of course be restored from a recent backup. But, as a > friend of mine put it recently, people don't need backup, they only need > restore ; ) If the disk is known to be bad, yes, and the number of bad blocks is growing. On the other hand, disks can and will have a few bad blocks, or bad writes that don't mean the disk is going bad, and a modern filesystem should be robust enough that a single failed sector doesn't cause the filesystem to go completely kaput. In fact, one of the scary trends with hard drives is that size is continuing to grow expoentially, access times linearly (more or less), and error rates (errors per kilobytes per unit time) are remaining more or less constant. The fact that reiserfs uses a single B-tree to store all of its data means that very entertaining things can happen if you lose a sector containing a high-level node in the tree. It's even more entertaining if you have image files (like initrd files) in reiserfs format stored in reiserfs, and you run the recovery program on the filesystem..... Yes, I know that reiserfs4 is alleged to fix this problem, but as far as I know it is still using a single unitary tree, with all of the pitfalls that this entails. Now, that being said, that by itself is not a reason not to decide not to include reseirfs4 into the mainline sources. (I might privately get amused when system administrators use reiserfs and then report massive data loss, but that's my own failure of chairty; I'm working on it.) For the technical reasons why resierfs4 hasn't been integrated, please see the mailing list archives. - Ted
From: Lexington Luthor <Lexington.Luthor@gmail.com> Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 18:26:03 +0100 Theodore Tso wrote: > If the disk is known to be bad, yes, and the number of bad blocks is > growing. On the other hand, disks can and will have a few bad blocks, > or bad writes that don't mean the disk is going bad, and a modern > filesystem should be robust enough that a single failed sector doesn't > cause the filesystem to go completely kaput. I never trust a single hard drive with data that cannot be instantly re-generated anyway (eg squid caches). The fact that some people have hardware errors should not require every single fs to accommodate random bad-sectors. Feel free to use ext3 or other fs which handles this situation (and other situations) better, but reiserfs works fine on good hardware. It has been my root filesystem on many systems with no problems whatsoever, even with cheap SATA drives. > In fact, one of the scary trends with hard drives is that size is > continuing to grow expoentially, access times linearly (more or less), > and error rates (errors per kilobytes per unit time) are remaining > more or less constant. > > The fact that reiserfs uses a single B-tree to store all of its data > means that very entertaining things can happen if you lose a sector > containing a high-level node in the tree. It's even more entertaining > if you have image files (like initrd files) in reiserfs format stored > in reiserfs, and you run the recovery program on the filesystem..... > > Yes, I know that reiserfs4 is alleged to fix this problem, but as far > as I know it is still using a single unitary tree, with all of the > pitfalls that this entails. > > Now, that being said, that by itself is not a reason not to decide not > to include reseirfs4 into the mainline sources. (I might privately > get amused when system administrators use reiserfs and then report > massive data loss, but that's my own failure of chairty; I'm working > on it.) For the technical reasons why resierfs4 hasn't been > integrated, please see the mailing list archives. > I read the archives, and most of the problems pointed out during the review were fixed relatively quickly, followed by a flame war due to some suggesting that reiser4 should not be able to affect VFS semantics, and other such matters (which IMO should be outside of the scope of a code review). There has been no follow-up review as far as I can tell. The discussion quickly degenerated into a personality argument against Mr Reiser, with several developers taking a strong position against reiser4 (the exact reasons for which are not specified). I don't quite know where reiser4 stands at the moment, given that it is in -mm and has been for a very long time. I also looked at the patch again, and it is indeed quite well isolated from the rest of the kernel so I don't understand why it is not being merged as an EXPERIMENTAL option. Regardless, it is available in -mm for anyone to use, and last I checked, works incredibly well leaving other filesystems miles behind in terms of speed. I haven't tested it enough to comment on the reliability, but if it is as reliable as reiserfs, it is sufficient for me and many others who use RAID and a UPS. Regards, LL
From: Theodore Tso [email blocked] Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 13:48:04 -0400 On Sun, Jul 16, 2006 at 06:26:03PM +0100, Lexington Luthor wrote: > I read the archives, and most of the problems pointed out during the > review were fixed relatively quickly, followed by a flame war due to > some suggesting that reiser4 should not be able to affect VFS semantics, > and other such matters (which IMO should be outside of the scope of a > code review). There has been no follow-up review as far as I can tell. As far as I know not all of the problems were fixed. And it has been observed that given the abuse and accusations that were directed at the people who did decide to review it, that it would not at all surprising if some (all?) of reviewers may have decided they had better things to do. Getting things merged into mainline is not a right, and the reviewers are volunteers..... Speaking for myself, since I don't enjoy being accused of partisanship and being ascribed of having a desire to backstab reiserfs, I have a personal policy to avoid reiserfs review, and recuse myself from any votes within program committee discussions regarding Hans Reiser. Being accused of taking unfair advantage of my volunteer activities is something I allow myself to get into once. - Ted
From: Diego Calleja [email blocked] Subject: "Why Reuser 4 still is not in" doc (was: 'reiserFS?') Date: Sun, 16 Jul 2006 22:01:15 +0200 El Sun, 16 Jul 2006 13:48:04 -0400, Theodore Tso [email blocked] escribió: > As far as I know not all of the problems were fixed. And it has been > observed that given the abuse and accusations that were directed at > the people who did decide to review it, that it would not at all > surprising if some (all?) of reviewers may have decided they had > better things to do. Getting things merged into mainline is not a > right, and the reviewers are volunteers..... Maybe it's too late and reiser 4 will get in in the next release, but I've written this doc into the kernelnewbies' wiki: http://wiki.kernelnewbies.org/WhyReiser4IsNotIn [12] . If you disagree with something in that doc, edit it or just answer to this mail what you want to see in it and I'll add it myself.
From: "Dr. David Alan Gilbert" [email blocked] Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 18:46:37 +0100 It is a sad reflection that we have these regular 'fs wars'; and that most of them are driven by peoples bad experiences with particular filesystems. That leads me to ask what level of testing is performed on each filesystem - are there filesystem torture tests that are getting run by someone (who?) on various filesystems (preferably on large TB sized ones, preferably with simulated failures and resets)? The discussions on Ext4 a few weeks ago made me think that the thing I'd value more than anything else would be a damn good test regime. It would be much nicer if the fs wars came down to peoples particularly good experiences with filesystems rather than people selecting file systems based on which one has lost them data most rarely. Dave P.S. For the record I use Reiser for large (>500GB) fs since I couldn't get Ext3 stable on one a year or so ago and xfs failed the 'recover from hitting reset' test. A couple of years ago I wouldn't touch Reiser because of NFS issues, but it seems to have grown out of that. -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org [13] |_______/
From: Theodore Tso [email blocked] Subject: Re: reiserFS? Date: Sun, 16 Jul 2006 14:14:31 -0400 On Sun, Jul 16, 2006 at 06:46:37PM +0100, Dr. David Alan Gilbert wrote: > That leads me to ask what level of testing is performed on each > filesystem - are there filesystem torture tests that are getting > run by someone (who?) on various filesystems (preferably on large > TB sized ones, preferably with simulated failures and resets)? > The discussions on Ext4 a few weeks ago made me think that the > thing I'd value more than anything else would be a damn good > test regime. As far as I know ext2/3 is the only filesystem with a fsck tool that has a regression test suite. It's always amazed me that filesystem consistency checkers and repair tools get so little attenion by most filesystem developers. As far as random torture testing, Pavel has written a random test tool that punches random errors into random blocks of a filesystem, and that was used to uncover a couple of cases that e2fsprogs didn't handle cleanly. Those were reported to me, and I fixed them, and the edge cases were encorprated into the regression test suite. IIRC it came up in discussion a few weeks ago one LKML or linux-fsdevel (I can't remember which), and I believe either someone from XFS or Reiser team was going to take Pavel's torture tester and adapt it do some robustifying of their filesystem's repair capabilities. Finally, the good folks at the Stanford Metacompilation group did some very interesting work to find bugs in three common Linux filesystems: http://keeda.stanford.edu/~junfeng/papers/osdi04/osdi04.html [14] Regards, - Ted
From: Caleb Gray [email blocked] Subject: Reiser4 Inclusion Date: Sun, 16 Jul 2006 20:02:15 -0700 Dear Linux Kernel Developers, I would like to express my experiences with the reiser4 filesystem and my reasons for its readiness to be officially included in the Linux kernel. I have been putting together servers since 2001, all of which are still operational and serving web sites reliably. The earliest servers I built used ext3 for their primary filesystems. Overtime I realized that I needed a faster filesystem for my servers' so I tried reiserfs. Those servers were, in fact, more responsive but carried several headaches into my life due to severe unreliability and so I was forced to convert all of the reiserfs servers to ext3. It wasn't until two years ago that I read about reiser4 and felt as though I should give the new reiser filesystem a chance. After two years of reiser4 and five years of ext3, I can attest to three things that reiser4 does just as well or better than ext3: speed, responsiveness, and reliability. This is not to say that reiser4 is _better_ than ext3, this is to simply say that it is as production ready as ext3 is. The reliability of reiser4 does _NOT_ compete with ext3 but it doesn't falter from it either. For every time that I have to run fsck.ext3, I have to run fsck.reiser4. Every time one of my servers crash, whether it's ext3 or reiser4, I spend the exact same amount of time recovering lost/broken files. And to note: the atomic file saving system that reiser4 implements has never caused me any issues during file recovery. Reiser4's responsiveness is undoubtedly at least twice as fast as ext3. I have deployed two nearly identical servers in Florida (I live in Washington state) but one difference: one uses ext3 and the other reiser4. The ping time of the reiser4 server is (on average) 20ms faster than the ext3 server. It has maintained this speed for the past two years against the ext3 server even with aging hardware and bulking file and directory structures. (Both of the filesystems have slowed down at a similar pace for the duration of their lifetime [about 15ms].) And finally reiser4's speed. I am constantly transferring files between other servers, and hard drives. The servers are also (obviously) serving data to the viewers of web sites, dealing with huge email queues (a few gigabytes every few hours), and handling heavy cron jobs to tarball user dirs from one drive to another. The reiser4 and ext3 servers deal with relatively the same amount of data to compress (~190GiB each), and the reiser4 is and always has been the first to finish. Not only finish first though, it generally finishes about 45 minutes before the ext3 server. (You can ignore the idea that it's probably the CPUs that can't handle the compression not the filesystems, because while the backup is running on both dual core processors the load never surpasses 45%; the bottleneck comes down to the throughput efficiency of data between drives.) The purpose of this email is not to bash ext3. As I have said I have a five year old ext3 server that runs great, and I intend to keep it that way. The reason that I have sent this is to present real life situations where reiser4 is reliable, fast, usable, and production ready. It is both realistic and reasonable to say that reiser4 is prepared to be officially supported in the Linux kernel. Please consider the fact that I have patched my servers' kernels time and time again, with all kinds of patches, and I have never once had an issue with the reiser4 patched kernels. Thank you for taking time away from development to read this email (I'm a programmer too), I know how it is. Sincerely, Caleb Gray
From: Arjan van de Ven [email blocked] Subject: Re: Reiser4 Inclusion Date: Mon, 17 Jul 2006 11:25:54 +0200 On Sun, 2006-07-16 at 20:02 -0700, Caleb Gray wrote: > Dear Linux Kernel Developers, > > I would like to express my experiences with the reiser4 filesystem and > my reasons for its readiness to be officially included in the Linux kernel. Hi, may I ask why you are sending this? Have you done code audits to the code? Have you done anything that was on the "these need fixing before it can go in" list? If not, aren't you just doing campaigning on non-technical grounds? And isn't that a bad idea? Arjan van de Ven -- who is starting to smell a directed PR campaign leading to allergic reactions
From: Grzegorz Kulewski [email blocked] Subject: Re: Reiser4 Inclusion Date: Mon, 17 Jul 2006 13:48:02 +0200 (CEST) Hi Arjan, On Mon, 17 Jul 2006, Arjan van de Ven wrote: > On Sun, 2006-07-16 at 20:02 -0700, Caleb Gray wrote: >> Dear Linux Kernel Developers, >> >> I would like to express my experiences with the reiser4 filesystem and >> my reasons for its readiness to be officially included in the Linux kernel. > > Hi, > > may I ask why you are sending this? Have you done code audits to the > code? Have you done anything that was on the "these need fixing before > it can go in" list? Well, as I understand he is end user (an advanced one). He does his job as a end user: he does testing and reports back the results. This is not that common, as many users do not report problems / requests they have. He even did more: he tested (very hard and extensively) experimental, not even in the tree part of the kernel. And he reported problems / ideas he found in a very kind and gentle way. This is not so common and makes him a valuable person in the users comunity in my opinion. As I understand you, as a developer, should say "thank you" to him and make everything you can to solve the problems he has and help implement the parts of the software he needs. No? That way you build comunity of users that not only are using the software but also are giving back in form of bug reports, feature requests, continuous testing on variety of setups (that no developer ever can have all), reviews, ideas, telling others about what a great software with friendly comunity they found and so on. For me (I am active end user of most open source projects and developer on others) the comunity and good contacs between developers and end users is the most important part of the software. It gives me security. Even if the software is not yet stable it can be fixed by cooperation between users and developers. While people are really way harder to fix than software. And he as a end user does not have to (and probably does not even have enough knowledge about the kernel internals) make code audits and review of new filesystem. So why are you demanding that he does one? > If not, aren't you just doing campaigning on > non-technical grounds? And isn't that a bad idea? Well, his kind message was not very technical. But wasn't completly non technical or flamewar either. He tested software, compared and reported what he saw. He also expressed wish (that many users have) that Reiser4, as a usefull and even useable in some production evironments, should be integrated into the kernel. Because there are users for it. > Arjan van de Ven -- who is starting to smell a directed PR campaign > leading to allergic reactions Come on. Another conspiracy theory? Why some people just can't understand that Reiser4 is not that bad (from end user's point of view)? Some people tested it and found it good and want to have it integrated ASAP. Some even can't live without it after they used it for a while and saw how good it is in something... I can assure you that it really is not some directed centrally controlled campaign. This is just what many users want. I too tested Reiser4 some time ago. It didn't have any big problems for me. But I am not using (or testing) it now. Why? Mainly because of security: if Reiser4 is not merged (even as a experminental, subject to change, unstable, whatever) it will work with new kernels as long as Namesys will release patches. And if something happens to Namesys I will have to port it to new kernels (and that is usually trivial for kernel developers introducing incompatible internal kernel API changes but not for me) myself or will have to use old kernels. And _that_ is a problem for me. (Not to mention that I am regulary applying 4-7 patches, some big ones, for every kernel I am building and resolving merge problems in not your code is not easy thing to do and takes time. While I can live without staircase scheduler or vesafb-tng if my manual merge attempt fails I can not do so without my main filesystem. And -mm is a little too unstable for me recently.) It is unfortunate that Hans Reiser pushed Reiser4 the way he did and that he got the reaction from some kernel developers he did got. But he and his developers did (and are still doing) very hard job to fix problems and make Reiser4 better and more suitable into the kernel. And having Reiser4 out of the kernel is hurting mainly end users. Really. Arjan, is this really technically impossible to have Reiser4 merged into the kernel after fixing some worst problems that touch mm and VFS (in say 2 months), flagged unofficial-try-merge-for-testing, super-experimental and subject-to-change? I would make live of many end users easier and does not sound that bad for me especially in the 2.6 forever era... If someone thinks that Reiser4 is too unstable or evil he can set it to N and be happy. And if Reiser4 will be abandoned by Namesys and not fixed further it could be maintained by kernel developers at a minimal level (porting to new kernel internal APIs as they change) for say 6-12 months while flagged for removal and then removed because of unofficial-try-merge-for-testing flag. This at least does give some time to migrate from it for end users (and maybe even time to fix it for some other developers?). Thanks and sorry for such long post, wrong as usual, Grzegorz Kulewski
From: Diego Calleja [email blocked] Subject: Re: Reiser4 Inclusion Date: Mon, 17 Jul 2006 16:06:18 +0200 El Mon, 17 Jul 2006 13:48:02 +0200 (CEST), Grzegorz Kulewski [email blocked] escribió: > If someone thinks that Reiser4 is too unstable or evil he can set it to N > and be happy. And if Reiser4 will be abandoned by Namesys and not fixed http://wiki.kernelnewbies.org/WhyReiser4IsNotIn [15]
From: Hans Reiser [email blocked] Subject: short term task list for Reiser4 Date: Tue, 11 Jul 2006 15:04:20 -0700 Please feel free to comment on this list and the order of its tasks: 0) fix all bugs as they arise 1) get batch_write into the -mm kernel --- small task 2) get read optimization code into the -mm kernel (coded and probably debugged but not fully tested and not sent in yet) --- small task 3) get EVERYTHING into wiki (migration has started already, thanks flx). 4) review complaints of pauses while using reiser4 --- size of task unknown, and it is also unknown how much we may have fixed it while writing recent patches. 5) review crypt-compress code --- full code review --- substantive task 6) optimize fsync --- substantive task which requires using fixed area for write twice logging, and using write twice logging for fsync'd data. It might require creating mount options to choose whether to optimize for serialized sequential fsyncs vs. lazy fsyncs. 7) review all of our installation instructions --- I am already doing that, but volunteers who will help out our wiki would be sorely appreciated. Installing reiser4 as the root for each distro needs step-by-step instructions. 8) review our kernel documentation --- I should do that but when will I have time? Unfortunately, our code stability is going to decrease for a bit due to all these changes to the read and write code --- no way to cure that but passage of time. On the other hand, our CPU usage went way down. Reiser4's only performance weakness now is fsync. Once the crypt-compress code is ready, we will release Reiser4.1-beta (with plugins, releasing a beta means telling users that if they mount -o reiser4.1-beta then cryptcompress will be their default plugin, and if they don't, then they are using Reiser4.0 still). Doubling our performance and halving our disk usage is going to be fun.
Related Links:
- Archive of above threads [thread 1 [16]] [thread 2 [17]]