login
Search
A brief thread on the lkml discussed whether or not Reiser4 would soon be stable enough to be merged into the 2.6 kernel as an 'experimental filesystem'. When it was suggested that this might be overly optimistic, that the filesystem may best go into the 2.7 development kernel [forum] first, Hans Reiser disagreed, "I don't think it is vastly optimistic, I hope we can send something in next month". He went on to explain, "we will have something we think is appropriate for inclusion as an experimental feature very soon now. Because our test scripts have become much more sophisticated, it means more when we say we cannot crash it, and it will go from experimental to stable faster than V3 did. I won't predict how fast."
Jens Axboe, maintainer of the block layer and several CD-ROM drivers, suggested that it would be unwise to merge the code so quickly, instead preferring a much lengthier period of user testing. He explains, "I don't doubt you have great testing scripts, but nothing beats real life testing." During a discussion in late August [story], 2.6 kernel maintainer Andrew Morton [interview] indicated that he would be willing to merge Reiser4 into his -mm patchset [howto].
From: Maciej Soltysiak [email blocked] To: [email blocked] Subject: Re: Linux 2.6.0 Date: Thu, 18 Dec 2003 10:48:50 +0100 > Wondering if ALSA and Latest Usb updates from Greg KH will make it into > 2.6.1 ? Is anything known about reiserfs4 becoming stable enough to be included some time soon. Maybe around 2.6.3-5 Regards, Maciej
From: Bill Davidsen[email blocked] Subject: Re: Linux 2.6.0 Date: 18 Dec 2003 16:17:05 GMT I think that's vastly optimistic. As Hans has reported, it's still pretty alpha as yet. And you can thank him for not releasing it until he's happy with it! I would guess it will be in 2.7 first, and backported when stable, but that's sure not my call, so feel free to disagree. -- bill davidsen [email blocked] CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
From: Hans Reiser [email blocked] Subject: Re: Linux 2.6.0 Date: Thu, 18 Dec 2003 22:31:03 +0300 bill davidsen wrote: >I think that's vastly optimistic. As Hans has reported, it's still >pretty alpha as yet. And you can thank him for not releasing it until >he's happy with it! I don't think it is vastly optimistic, I hope we can send something in next month, but you probably know how hard it is to estimate the time to the last findable bug for a large project like ours. -- Hans
From: Jens Axboe [email blocked] Subject: Re: Linux 2.6.0 Date: Thu, 18 Dec 2003 20:42:03 +0100 On Thu, Dec 18 2003, Hans Reiser wrote: > I don't think it is vastly optimistic, I hope we can send something in > next month, but you probably know how hard it is to estimate the time to > the last findable bug for a large project like ours. Not to mention the months long period of actually getting user testing and fixing all of those bugs before it's qualifiable for kernel inclusion. I hope you don't expect to actually have something that's worthy of being merged into 2.6.x in a months time? -- Jens Axboe
From: Hans Reiser [email blocked] Subject: Re: Linux 2.6.0 Date: Fri, 19 Dec 2003 06:42:02 +0300 Jens Axboe wrote: >I hope you don't expect to actually have something that's worthy of >being merged into 2.6.x in a months time? Have you looked at the stability of the typical experimental feature? If we used that as a guide, we'd have sent it in 3 months ago.....;-) We will have something we think is appropriate for inclusion as an experimental feature very soon now. Because our test scripts have become much more sophisticated, it means more when we say we cannot crash it, and it will go from experimental to stable faster than V3 did. I won't predict how fast. -- Hans
From: Jens Axboe [email blocked] Subject: Re: Linux 2.6.0 Date: Fri, 19 Dec 2003 07:57:47 +0100 On Fri, Dec 19 2003, Hans Reiser wrote: > Have you looked at the stability of the typical experimental feature? > If we used that as a guide, we'd have sent it in 3 months ago.....;-) I don't think that's true. Plus, a file system (even more true in the case of reiser4) is a huge complex beast. A driver is a lot less complex. > We will have something we think is appropriate for inclusion as an > experimental feature very soon now. Because our test scripts have > become much more sophisticated, it means more when we say we cannot > crash it, and it will go from experimental to stable faster than V3 > did. I won't predict how fast. Well v3 was merged too soon to, but at that time there was a big motive to do just that - get a journalled fs in the kernel. With v4 that just isn't the case. I don't doubt you have great testing scripts, but nothing beats real life testing. -- Jens Axboe
Bring it on
It's clear the Reiser team are just itching to have this merged. It'll be marked as an experimental fs, and noone has to use it unless they want to. Linus could do better than to piss off a company that's so willing to donate resources to make Linux better. Code-contributing friends don't come cheap, and Reiser4 is a very interesting filesystem to boot.
bad idea...
you cant just go around merging untested drivers when there is no reason. It must be understood that there is no reason to dump things into the kernel when it hasn't been fully tested. Because when its known to not be stable enough, u will have people who try it, get filesystem corruption, not notice those corruption problems untillater and the list will be flooded later by problems caused by an experimental version. And then you'll have ur typical corporate idiot who complains when it screws up, because his distribution allowed the creation of reiser4 partitions, without it saying it was developmental, because the kernel came precompiled.
Anyway, I'd imagine there are patches available you can use yourself if you want reiser4 that bad (and anyone could patch their own kernel). Linus always has his reasons, and if u dont trust him, you could always make ur own patchset, or even your own kernel. But the moment u start merging every untested patch, which hasn't even been in a major patchset, you start accidently merging patches that causes the kernel to jam, crash, and have other modules that start doing the same kind of thing, and in filesystems, weird effects caused by corruption, and the only one of those easily traced down to the filesystem is probably the last. The idea is to make sure things work one at a time to help debugging. Otherwise u get weird bugs happening that cause a headache for all the kernel programmers..
At this point of time, the only ppl who would want to use reiser4 anyway, are people who run it in vmware, or are just messing around, so honestly, I think it would be a rediculous idea at this point.. at the very least Linus should wait until some distributions have offered it as a developmental filesystem, or even more, have it in a devel patcheset .. I doubt he would wait until 2.7 anyway, i'm guessing he would probably merge it within the next 6 months.
Something just tells me that linus, rusty, andrew morton and the rest of the kernel team understands more what they are doing then us to be honest, but if u dont think they are, u could always fork 2.6.. because thats what open source is about, the ability to innovate
Not why things get merged
One of the things that this community seems to pride itself on is evaluating code on its technical merits. If it is merged, the reason shouldn't be so as not to 'piss off' anyone. Appeasing friends is not a reason to merge code.
However, a user trial as axboe suggested, perhaps into a tree like -mm or -wli would seem to be the way to go. The Namesys teams efforts should be greatly appreciated for their patience, their fs expertise, and modular design that leaves way for some interesting ideas (directories as files, possible lsm extensions, overall modular design)
It would be nice to see reiser4 in -mm or -wli,. allowing other core developers time to get comfortable with it, and to provide Reiser's team with valuable user feedback.
some problems
Let me say that I hope Reiser4 gets merged, but its not just a case of marking it experimental like most device drivers. It does touch quite a lot of core code. Now hopefully they have those pieces broken down in to small, obviously correct changes but typically (not of namesys, but out of tree projects in general) this is not the case. Still, it will hopefully get there eventually.
A while ago Andrew Morton did say that he wouldn't be against adding new filesystems to the stable kernel - he would consider Reiser4 when Hans thinks its ready.
Precisely
Precisely. The thing is, it's file system code. It's not like including a different MP3 player with a distribution.. it's including a file system with a kernel. I'm a big fan of Reiser3, but I'd have no problems with seeing Reiser4 initially consigned to 2.7, with a merge to 2.6 later on down the track.
I agree with a previous poster who said the technical testing bit isn't everything, and that the real world can bring out some totally bizarre flaws. Then again, Reiser is pretty established now ;-)
Re: Bring it on
There are lots of people out there who want to see Reiser4 merged, like me, but really Linus is trying to be much more conservative in what gets merged. Reiser wants to get the fs merged so that it can be widely deployed to get real user testing. Now that 2.6 has been released I think that it is more likely to see merger, because the kernel will be back into a position of feature growth, one a stable release or two is out. The major consideration of merger is will it destablize the kernel as a whole, and will Reiser get egg on his face like has happened with early 2.4 kernels.
should be noted
that early 2.4.x issues were vm related,. not reiserfs per se. I know most people here know that, but it seemed ambiguous from the context.
I'm all for it
I'm running it now for not really long (since -test9), but i'm using it extensively as all my multimedia data is on a 50GB reiser4 paritition, and that partition is also being used for compiling stuff which i'm doing all the time.
The bottom line is that i'm using reiser4 "normally" and quite heavily and i haven't had any problems with it, also it seems to be less prone to recoverage problems when having had a system crash, but that may be only a placebo effect with no technical substance ;)
I would say it shouldn't be integrated all too fast, but i don't think it needs more than (just rough estimation) say 3 or max. 4 months of further testing.
Maybe namesys.com could provide a central/unified mechanism for reporting problems with reiser4?
re: I'm all for it
You should post bug reports to the reiserfs mailing list Reiserfs-List@Namesys.COM.
Also, reiserfs developers are available at the
irc://irc.oftc.net/#reiser4, but keep in mind that we are in the Moscow time zone (GMT+3).
Reiser4 ready (sort of)
I tried it briefly using it as var/spool and bulding a largest chess database with SCID. It seemed to work fine if it was on one smallish 1 GB partition. I ran into segmentation fault problems when using it for a second 2.5GB partition on an old second ATA-33 HD during unmounting or kernel shutdown. I've run reiserfs on both of these partitions with no problems for over a year. The not remountable problem is well known. This second seems more serious. I am slapping myself for not sending it the logs. I'll try again this week.
Better to put Reiser4 on kernel-2.7.x
And later we will put Reiser4 backward to kernel-2.6.14 by example when it's very stable.
It's like kernel-2.4.23 does with newer stable patches.
I'll use it
Personally I can't wait for them to say they can't crash it and I'll put everything over to reiser4.
It's not like someone's going to encounter Reiser4 for the first time when compiling a kernel with the 'experimental' label and suddenly get this urge to make a whole swag of 'experimental' reiser4 partitions and put important stuff on it. It's code is also not intrusive (unlike earlier XFS patches) so it is easy to assess it's impact on the kernel when it is not compiled in (ie none). It makes no difference to me whether it's in the mainline kernel or a separate patch; patching is easy for the sort of person trying experimental FS. However I don't see any problem with including it in mainline to avoid the need for alternate trees as early as 2.6.0.
aujsydje
[URL=http://doaxdfnq.com]dlualiti[/URL] hmvbdrnn gvojclbk http://urgxqasm.com mmrrghhj twjmdxmy