![]() | |||||||||||||
Messages in this thread |
the last time I've tried Reiser4 in -mm (4 - 6 weeks ago approxamitely) I managed to oops by doing: $ tar xfjv linux-2.6.17.tar.bz2 $ sync I was calling sync because I was curious as to why XFS seemed to sync all the time and look and feel slow when compared to ext3. So I thought let's see what Reiser4 does and the moment I ran sync it oopsed. Yes this could be a problem with that particular -mm version. I'd be interested to hear whether this still happens. no, I'm not making any statements about code quality just curious to hear as you seem to be using Reiser4 successfully. On 7/17/06, Grzegorz Kulewski <kangur@polcom.net> wrote: > On Mon, 17 Jul 2006, Diego Calleja wrote: > > El Mon, 17 Jul 2006 13:48:02 +0200 (CEST), > > Grzegorz Kulewski <kangur@polcom.net> 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 > > I already read it when it was posted first. I am reading LKML and > reiserfs-list for several years and I already read all that arguments, > flames and so on that were ever pointed here. I think I have enough. > > But if we are there: > > ""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." > > Why do some people think that users are not already depending on it? They > are. I don't know how much but I am willing to bet that at least 100 > people. I think that there are some drivers in the kernel that have > smaller user base. > > Keeping Reiser4 out of kernel is even worse (for those users, other users > that could test this filesystem, for Reiser4 developers and whole > comunity) than accepting it for a try period with a big fat warning that > it my be removed if Namesys abandons futher fixing of it (after some time > to let user migrate). > > And any arguments like "if Reiser4 is not in the kernel then people will > not use and depend on it" are fundamentally flawed IMHO. Everything bad > that could happen with Reiser4 in the kernel can happen with Reiser4 out > of it. > > It may look like some kernel developers are trying hard not to take > responsibility for Reiser4 saying that there is very huge difference > between selecting highly experimental kernel feature that is marked so and > patching the kernel with it. Sorry but I think there is very little > difference. And that little difference is only hurting users that want to > try and test something new. > > > Thanks, > > Grzegorz Kulewski > > > PS. I really don't want to begin World War 4 about Reiser4. I just think > that curious people asking from time to time about _current_ Reiser4 > status should not be treated bad because that could make them stop > testing and giving back to the open source projects. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-07-17 17:55 [from the cache] ©2003-2008 | |||||||||||||