login
Search
Hans Reiser [interview] sent an email to the lkml titled, "I request inclusion of reiser4 in the mainline kernel". He provided a list of objections raised earlier, noting that all had been addressed. Among the listed issues, Reiser4 now works with 4k stacks. "There have been no bug reports concerning the new code," Hans added.
The request was followed with some suggestions by Christoph Hellwig, including general comments about the coding style. This was one of many issues that led to debate in which Hans commented, "most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code. So yes, it is different." Alan Cox [interview] replied that while the kernel coding style isn't his own style, he tries to follow it when working on the kernel, "one big reason we jump up and down so much about the coding style is that its the one thing that ensures someone else can maintain and fix code that the author has abandoned, doesn't have time to fix or that needs access to specific hardware the authors may not have." Much of the rest of the thread was less friendly, leaving the question of merging Reiser4 into the mainline kernel still up in the air.
From: Hans Reiser [email blocked]
To: Andrew Morton [email blocked], Linus Torvalds [email blocked]
Subject: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 10:05:08 -0700
All objections have now been addressed so far as I can discern.
The VFS layering issue was addressed after 2 months of recoding.
The undesired type safe lists were removed after ~ a man week of coding.
Cosmetic issues regarding line length, etc., were addressed.
Numerous ~ one line changes were made that I will not address here.
The assertions were left in, with akpm's ok.
Pseudo files were removed.
dependency on !4k stacks was removed and stack usage was fixed.
reiser4_drop_inode was removed.
our div64_32 was replaced with the linux one
I request that reiser4 be included. Technically, we submitted 9 months
before the deadline for 2.6.14, though I am sure the point will be
argued. We would have submitted our feedback fixes on monday but we
lost the type safe lists argument over the weekend before monday, so it
delayed us.
There have been no bug reports concerning the new code.
If we get lucky, we might also have a compression plugin working by the
time 2.6.14 ships, it just needs some mmap fixes to work. Then the
benchmarks will be truly excessive..... even after we rewrite them
because they currently generate files that compress too well to be
realistic.....
:)
Thanks to all for your kind suggestions of improvements to our work, and
the time you invested in providing us with feedback. It will be easier
to use meta-. to browse our code now that the type safe lists are gone,
etc., etc.
Hans
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 18:15:09 +0100
On Fri, Sep 16, 2005 at 10:05:08AM -0700, Hans Reiser wrote:
> All objections have now been addressed so far as I can discern.
>
> The VFS layering issue was addressed after 2 months of recoding.
>
> The undesired type safe lists were removed after ~ a man week of coding.
>
> Cosmetic issues regarding line length, etc., were addressed.
>
> Numerous ~ one line changes were made that I will not address here.
>
> The assertions were left in, with akpm's ok.
>
> Pseudo files were removed.
>
> dependency on !4k stacks was removed and stack usage was fixed.
>
> reiser4_drop_inode was removed.
>
> our div64_32 was replaced with the linux one
You completely ignore my last review comments. And that was just the
errors sticking out from an half an error look. I'll do a deeper review,
but ocfs has a higher priority right now.
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 18:40:28 +0100
more trivial review comments ontop of the previous one, after looking
at things:
- please never use list_for_each in new code but list_for_each_entry
- never use kernel_thread in new code but kthread_*
- do_sendfile duplicates the common sendfile code. why aren't you
using the generic code?
- there's tons of really useless assertation of the category
discussed in the last thread
- there's tons of deep pagecache messing in there. normally this
shouldn't be a filesystem, and if this breaks because of VM changes you'll
have to fix it, don't complain..
- you still do your plugin mess in ->readpage. honsetly could you
please explain why mpage_readpage{,s} don't work for you?
- (issues with the read/write path already addresses in the previous thread)
- looking at ->d_count in ->release is wrong
- still has security plugin stuff that duplicates LSM
- why do underlying attributes change when VFS inode doesn't change?
if not please rip out most of getattr_common
- link_common S_ISDIR doesn't make sense, VFS takes care of it
- please use the generic_readlink infrastructure
additinoal comment is that the code is very messy, very different
from normal kernel style, full of indirections and thus hard to read.
real review will take some time.
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 12:39:48 -0700
Christoph Hellwig wrote:
>additinoal comment is that the code is very messy, very different
>from normal kernel style, full of indirections and thus hard to read.
>
Most of my customers remark that Namesys code is head and shoulders
above the rest of the kernel code. So yes, it is different. In
particular, they cite the XFS code as being so incredibly hard to read
that its unreadability is worth hundreds of thousands of dollars in
license fees for me. That's cash received, from persons who read it
all, not commentary made idly.
May I suggest that you work on the XFS code instead? Surely with all of
this energy you have, you could improve XFS a lot before it gets
accepted into the kernel.
As for the indirections, if you figure out how to make VFS indirections
easy to follow, the same technique should be applicable to Reiser4, and
I will be happy to fix it.
Hans
(Note for the record: I actually think XFS acceptance was delayed too
long, and I think that XFS is a great filesystem, but a rhetorical point
needed to be made......)
From: Kyle Moffett [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Fri, 16 Sep 2005 15:52:45 -0400
[CC list trimmed to relevant people, no need to spam Linus' and
Andrew's mailboxes, they have enough to do as it is]
On Sep 16, 2005, at 15:39:48, Hans Reiser wrote:
> Christoph Hellwig wrote:
>> additinoal comment is that the code is very messy, very different
>> from normal kernel style, full of indirections and thus hard to read.
>
> Most of my customers remark that Namesys code is head and shoulders
> above the rest of the kernel code. So yes, it is different.
And yet thousands and thousands of people, businesses, etc, say that
the Linux kernel code is miles above all the commercial software out
there. Please leave the worthless rhetoric out of a technical
discussion. The issue stands that in many ways the Reiser4 code does
not exactly follow Documentation/CodingStyle and does not match most
of the rest of the kernel, making it hard to read for other kernel
developers. If you were just doing this forever as an external
kernel patch, nobody would give a damn. On the other hand, you're
trying to get it included in the upstream kernel, which means that
those same "other kernel developers" for whom it is hard to read may
be expected to maintain it until the end of time. Given this, it
seems perfectly reasonable to ask that it be cleaned up.
> In particular, they cite the XFS code as being so incredibly hard
> to read that its unreadability is worth hundreds of thousands of
> dollars in license fees for me.
How does XFS have _anything_ to do with Reiser4? A technical
discussion is no place for political pissing contest.
> [more useless posturing snipped]
> As for the indirections, if you figure out how to make VFS
> indirections easy to follow, the same technique should be
> applicable to Reiser4, and I will be happy to fix it.
That's not his responsibility, it's _yours_. If you want your stuff
included in the the kernel, you need to make sure it is sufficiently
acceptable. Besides, this is just one complaint of the many he
made. This may not be particularly solvable, but there are a number
of other points he made that you guys need to try to resolve.
> (Note for the record: I actually think XFS acceptance was delayed
> too long, and I think that XFS is a great filesystem, but a
> rhetorical point needed to be made......)
See above. Rhetoric has little or no place here. Such comments are
why Reiser4 typically triggers massive flamewars when it is mentioned
on the LKML.
Cheers,
Kyle Moffett
--
Somone asked me why I work on this free (http://www.fsf.org/
philosophy/) software stuff and not get a real job. Charles Shultz
had the best answer:
"Why do musicians compose symphonies and poets write poems? They do
it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life."
-- Charles Shultz
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 13:51:57 +0300
On Friday 16 September 2005 22:52, Kyle Moffett wrote:
> [CC list trimmed to relevant people, no need to spam Linus' and
> Andrew's mailboxes, they have enough to do as it is]
>
> On Sep 16, 2005, at 15:39:48, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> >> additinoal comment is that the code is very messy, very different
> >> from normal kernel style, full of indirections and thus hard to read.
> >
> > Most of my customers remark that Namesys code is head and shoulders
> > above the rest of the kernel code. So yes, it is different.
>
> And yet thousands and thousands of people, businesses, etc, say that
> the Linux kernel code is miles above all the commercial software out
> there. Please leave the worthless rhetoric out of a technical
> discussion. The issue stands that in many ways the Reiser4 code does
> not exactly follow Documentation/CodingStyle and does not match most
> of the rest of the kernel, making it hard to read for other kernel
> developers. If you were just doing this forever as an external
> kernel patch, nobody would give a damn. On the other hand, you're
> trying to get it included in the upstream kernel, which means that
> those same "other kernel developers" for whom it is hard to read may
> be expected to maintain it until the end of time. Given this, it
> seems perfectly reasonable to ask that it be cleaned up.
I think it makes sense to supply examples from reiser4 code
which you want to be changed. "It's ugly" is not specific enough.
--
vda
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:01:41 -0700
Denis Vlasenko wrote:
>
>>And yet thousands and thousands of people, businesses, etc, say that
>>the Linux kernel code is miles above all the commercial software out
>>there.
>>
Not the commercial software I have worked with. IBM code, government
procured code, both are much more readable code than Linux Kernel
standards. I am sure there is no shortage of bad IBM code and bad
government code, but my personal experiences were that it was much
better commented. Your statement sounds like something you want to
believe.
That all said, the kernel code is getting better..... if the rest of
the kernel was as well commented as akpm's code I would not be
complaining at all.
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 10:22:47 +0100
On Fri, Sep 16, 2005 at 12:39:48PM -0700, Hans Reiser wrote:
> Christoph Hellwig wrote:
>
> >additinoal comment is that the code is very messy, very different
> >from normal kernel style, full of indirections and thus hard to read.
> >
>
> Most of my customers remark that Namesys code is head and shoulders
> above the rest of the kernel code. So yes, it is different. In
> particular, they cite the XFS code as being so incredibly hard to read
> that its unreadability is worth hundreds of thousands of dollars in
> license fees for me. That's cash received, from persons who read it
> all, not commentary made idly.
It's very different from kernel style, and it's hard to read for us kernel
developers. And yes, I don't think XFS is the most easy to read code either,
quite contrary. But it's at least half a magnitude less bad than reiser4
code..
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 13:56:14 +0300
On Saturday 17 September 2005 12:22, Christoph Hellwig wrote:
> On Fri, Sep 16, 2005 at 12:39:48PM -0700, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> >
> > >additinoal comment is that the code is very messy, very different
> > >from normal kernel style, full of indirections and thus hard to read.
> > >
> >
> > Most of my customers remark that Namesys code is head and shoulders
> > above the rest of the kernel code. So yes, it is different. In
> > particular, they cite the XFS code as being so incredibly hard to read
> > that its unreadability is worth hundreds of thousands of dollars in
> > license fees for me. That's cash received, from persons who read it
> > all, not commentary made idly.
>
> It's very different from kernel style, and it's hard to read for us kernel
> developers. And yes, I don't think XFS is the most easy to read code either,
> quite contrary. But it's at least half a magnitude less bad than reiser4
> code..
At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time
to optimize code size, but:
reiser4 2557872 bytes
xfs 3306782 bytes
--
vda
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sat, 17 Sep 2005 14:15:50 +0300
> At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time
> to optimize code size, but:
>
> reiser4 2557872 bytes
> xfs 3306782 bytes
And modules sizes:
reiser4.ko 442012 bytes
xfs.ko 494337 bytes
--
vda
From: Chris White [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 09:34:45 +0900
CC-List trimmed
On Saturday 17 September 2005 20:15, Denis Vlasenko wrote:
> > At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more
> > time to optimize code size, but:
> >
> > reiser4 2557872 bytes
> > xfs 3306782 bytes
>
> And modules sizes:
>
> reiser4.ko 442012 bytes
> xfs.ko 494337 bytes
All this is fine and dandy, but saying "My code is better than yours!!" still
doesn't solve the issue this thread hopes to achieve, that being "I'd like to
get reiser4 into the kernel". There seems to be a lot of (historical?)
tension present here, but all that seems to be doing is making things worse.
PLEASE keep this thing a tad on par. Keeping this up is hurting everyone
more than helping. I wish I could say something as simple as "let's just be
friends", but that's saying a lot. I can say this though: this is open
source, and that means that our source is open, and we should be too.
Chris White
From: Denis Vlasenko [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 13:21:23 +0300
On Sunday 18 September 2005 03:34, Chris White wrote:
> CC-List trimmed
>
> On Saturday 17 September 2005 20:15, Denis Vlasenko wrote:
> > > At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more
> > > time to optimize code size, but:
> > >
> > > reiser4 2557872 bytes
> > > xfs 3306782 bytes
> >
> > And modules sizes:
> >
> > reiser4.ko 442012 bytes
> > xfs.ko 494337 bytes
>
> All this is fine and dandy, but saying "My code is better than yours!!" still
> doesn't solve the issue this thread hopes to achieve, that being "I'd like to
> get reiser4 into the kernel". There seems to be a lot of (historical?)
> tension present here, but all that seems to be doing is making things worse.
> PLEASE keep this thing a tad on par. Keeping this up is hurting everyone
> more than helping. I wish I could say something as simple as "let's just be
> friends", but that's saying a lot. I can say this though: this is open
> source, and that means that our source is open, and we should be too.
I am trying to say that I think that Hans is being treated a bit unfairly.
His fs is new and has fairly complex on-disk structure and complex journalling
machinery, yet his source and object code is smaller than xfs which already
is accepted. This is no easy feat I guess.
Maybe xfs shouldn't be accepted too, this may be an answer.
Let's look at the code. Hans' code is not _that_ awful. Yet people
(not all of them, but some) do not point to specific things which they
want to be fixed/improved. I see blanket arguments like "your code is hard
to read". Well. Maybe spend a minute on what exactly is hard to read,
or do we require Hans to be able to read minds from the distance?
This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
good code review".
--
vda
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 11:26:58 +0100
On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> good code review".
After he did his basic homework. Note that reviewing hans code is probably
at the very end of everyones todo list because every critizm of his code
starts a huge flamewar where hans tries to attack everyone not on his
party line personally.
I've said I'm gonna do a proper review after he has done the basic homework,
which he seems to have half-done now at least. Right now he hasn't finished
that and there's much more exciting filesystems like ocfs2 around that
are much easier to read and actually have developers that you can have
a reasonable conversation with. (and that unlike hans actually try to
improve core code where it makes sense for them)
From: michael chang [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 13:22:27 -0400
On 9/18/05, Christoph Hellwig [email blocked] wrote:
> On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> > This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> > good code review".
>
> After he did his basic homework. Note that reviewing hans code is probably
> at the very end of everyones todo list because every critizm of his code
> starts a huge flamewar where hans tries to attack everyone not on his
> party line personally.
>
> I've said I'm gonna do a proper review after he has done the basic homework,
> which he seems to have half-done now at least. Right now he hasn't finished
Explain to us all what is this "basic homework" of which you speak.
> that and there's much more exciting filesystems like ocfs2 around that
This is exciting to... whom? The only thing that appears remotely
interesting about it is that it's made by Oracle and apparently is
supposed to be geared toward parallel server whatsits. This might be
helpful to corporations, but seems senseless toward many consumers.
(I'm assuming there's still at least one consumer left who still uses
Linux.)
> are much easier to read and actually have developers that you can have
> a reasonable conversation with. (and that unlike hans actually try to
Is that Hans' fault, or the fault of your lot? Why can't we all just get along?
Give Hans a chance; and please try to understand, even if he's hard to
work with. Discriminate him because he's not a developer you can talk
with, and I believe that's like discriminating a guy in a wheelchair
because he can't run with you when you jog in the morning.
> improve core code where it makes sense for them)
Not everyone has the same "common sense" that you do. Explain, fully,
with reasoning, and reproducable back-up statistics on common
hardware, what code is wrong, and what must be written instead. We'd
like to be efficient, and it's not being efficient to play a guessing
game with us. If you don't have the time to review, then please hold
off on replying until you have a through review of at least part of
the code.
Unless you object fully to one particular, fixable thing that isn't
the core of Reiser4, it'd be nice for you to wait on replying --
vagueness is not helpful to development in any way. Are we supposed
to be the million monkeys randomly typing on a million typewriters
waiting for someone to give you code that you like, one in a million
years?
Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
or ext2 or ext3 had never gotten into the kernel. How would their
development be now as opposed to how we see it, when they have gotten
into the kernel? I don't see anything wrong with the idea of letting
what seems a mostly mature FS into the kernel; that is how most bugs
are found in the first place. Of course, there is nothing wrong with
putting huge warnings on the FS; I'd recommend them, considering that
some people are having funky problems with the patch.
I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
Indeed, H.264 crashes some computers, similar to Reiser4 might crash
some machines, but this is merely because Reiser4 explores new
concepts, meaning it may require hardyier hardware than ext2/3, as
H.264 requries hardier hardware than Mpeg-2. I believe that the
concept is the same. (And all the same, media companies are embracing
H.264 - why can't you guys embrace this new idea also?) Change is
hard. Besides, if Reiser4 is truely that flawed, we will see in a few
releases, and then afterwards if it's proven to everyone that Reiser4
is completely unrepairable and hopeless, it can then be ditched and
thrown into the trash.
My apologies for my rudeness, but I am rather fond of the developments
in Reiser4, and would love to see it in the kernel. I am fond of
Linux too, and the work that you guys do, and it would dissapoint me
sorrily if Reiser4 never makes it into the Linux kernel. Feel free to
say I'm a tad biased; I will say now that I probably have much less
merit in the field than you guys do.
--
~Mike
- Just my two cents
- No man is an island, and no man is unable.
From: Horst von Brand [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 16:04:19 -0400
michael chang [email blocked] wrote:
> On 9/18/05, Christoph Hellwig [email blocked] wrote:
> > On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
> > > This is it. I do not say "accept reiser4 NOW", I am saying "give Hans
> > > good code review".
> > After he did his basic homework. Note that reviewing hans code is probably
> > at the very end of everyones todo list because every critizm of his code
> > starts a huge flamewar where hans tries to attack everyone not on his
> > party line personally.
> > I've said I'm gonna do a proper review after he has done the basic
> > homework, which he seems to have half-done now at least. Right now he
> > hasn't finished
> Explain to us all what is this "basic homework" of which you speak.
The required cleanups have been posted (in outline at least), several
times, by unrelated people.
> > that and there's much more exciting filesystems like ocfs2 around that
> This is exciting to... whom?
To Cristoph, obviously. You should thank him for doing the (hard, boring,
thankless) work of reviewing code for free. Even if it isn't yours. As he
is doing it as community service, I wouldn't dare blame him for picking
whatever he likes most, for whatever reasons.
> The only thing that appears remotely
> interesting about it is that it's made by Oracle and apparently is
> supposed to be geared toward parallel server whatsits. This might be
> helpful to corporations, but seems senseless toward many consumers.
Cristoph finds it interesting, that should be enough for everybody not
paying him for doing the work.
> (I'm assuming there's still at least one consumer left who still uses
> Linux.)
Count me in. That doesn't mean I agree with ReiserFS' goals...
> > are much easier to read and actually have developers that you can have
> > a reasonable conversation with. (and that unlike hans actually try to
> Is that Hans' fault, or the fault of your lot? Why can't we all just get
> along?
Hans is one person, and he has managed to alienate a most of the LKML
bunch. Sure, there are very abrasive people here, but there are plenty that
are extremely helpful to newbies that /really/ want to learn how to do
things right.
> Give Hans a chance; and please try to understand, even if he's hard to
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
Please consider that most people here are volunteers, they owe nobody
nothing. Quite the contrary: if somebody wants to unload their code (and
its future maintenance) on the kernel crew, they are in /great/ debt if it
gets accepted.
> > improve core code where it makes sense for them)
> Not everyone has the same "common sense" that you do. Explain, fully,
> with reasoning, and reproducable back-up statistics on common hardware,
> what code is wrong, and what must be written instead. We'd like to be
> efficient, and it's not being efficient to play a guessing game with us.
> If you don't have the time to review, then please hold off on replying
> until you have a through review of at least part of the code.
Can't do. It is mostly an artistic sense of taste.
> Unless you object fully to one particular, fixable thing that isn't the
> core of Reiser4, it'd be nice for you to wait on replying -- vagueness is
> not helpful to development in any way. Are we supposed to be the million
> monkeys randomly typing on a million typewriters waiting for someone to
> give you code that you like, one in a million years?
You are the ones that want to benefit from having your code in the kernel.
You evaluate if the (standard!) cycle of "Code, propose, get rejected, fix,
repropose, ... until finally accepted" works for you or just isn't worth
the bother.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> or ext2 or ext3 had never gotten into the kernel. How would their
> development be now as opposed to how we see it, when they have gotten
> into the kernel? I don't see anything wrong with the idea of letting
> what seems a mostly mature FS into the kernel; that is how most bugs
> are found in the first place. Of course, there is nothing wrong with
> putting huge warnings on the FS; I'd recommend them, considering that
> some people are having funky problems with the patch.
Just unloading some untested code on unsuspecting, innocent users is not
very nice, is it?
> I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
> Indeed, H.264 crashes some computers, similar to Reiser4 might crash
> some machines, but this is merely because Reiser4 explores new
> concepts, meaning it may require hardyier hardware than ext2/3, as
> H.264 requries hardier hardware than Mpeg-2.
Either one crashing the machine is unacceptable (in principle at least). A
filesystem is so central to "everything is a file" that filesystem problems
are doubly unacceptable. There are lots of reports of ReiserFS 3
filesystems completely destroyed by minor hardware flakiness. And that has
/never/ been fixed, as the developers just went off to do the "next cool
thing". That history weighs against ReiserFS, heavily.
> I believe that the
> concept is the same. (And all the same, media companies are embracing
> H.264 - why can't you guys embrace this new idea also?) Change is
> hard. Besides, if Reiser4 is truely that flawed, we will see in a few
> releases, and then afterwards if it's proven to everyone that Reiser4
> is completely unrepairable and hopeless, it can then be ditched and
> thrown into the trash.
It is cheaper for everybody involved to throw it in the thrash /before/
lots of people are dependent on it, and throw it out then. Just consider
the pain caused by including (and now ditching) devfs.
> My apologies for my rudeness, but I am rather fond of the developments
> in Reiser4, and would love to see it in the kernel. I am fond of
> Linux too, and the work that you guys do, and it would dissapoint me
> sorrily if Reiser4 never makes it into the Linux kernel. Feel free to
> say I'm a tad biased; I will say now that I probably have much less
> merit in the field than you guys do.
All this has been discussed in BIGNUM flamewars already, neither your nor
my post helps a bit in either way (except in fanning the flames), so please
let's drop this.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:44:04 -0700
Horst von Brand wrote:
>
>>>that and there's much more exciting filesystems like ocfs2 around that
>>>
>>>
>
>
>
>>This is exciting to... whom?
>>
>>
>
>To Cristoph, obviously. You should thank him for doing the (hard, boring,
>thankless) work of reviewing code for free. Even if it isn't yours. As he
>is doing it as community service, I wouldn't dare blame him for picking
>whatever he likes most, for whatever reasons.
>
>
Well maybe he should just go away then and save his and our time.
Reiser4 works just fine without Christoph. Users are happy with it.
None of them have asked for his help. I don't consider Christoph to be
qualified to work on our filesystem. I would not hire him if he applied
--- he is not capable of innovative work.
Reiser4 is far from perfect, but it is ready for more users.
>
>>Is that Hans' fault, or the fault of your lot? Why can't we all just get
>>along?
>>
>>
>
>Hans is one person, and he has managed to alienate a most of the LKML
>bunch. Sure, there are very abrasive people here, but there are plenty that
>are extremely helpful to newbies that /really/ want to learn how to do
>things right.
>
>
Yes, but the helpful ones have nothing to do with VFS. Linux has lost
filesystem developers because of the VFS team, developers who I can tell
you were very very gifted DARPA researchers who decided to work on BSD
because they had too much dignity to develop a filesystem for Linux. I
assure you that no one on the VFS team is as bright or capable as one of
the fellows I know of that they abused away.
>>If you don't have the time to review, then please hold off on replying
>>until you have a through review of at least part of the code.
>>
>>
>
>Can't do. It is mostly an artistic sense of taste.
>
>
Yes, which is why people who have not written a serious filesystem
should not instruct those who have written the measurably fastest one.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
>
>>or ext2 or ext3 had never gotten into the kernel. How would their
>>development be now as opposed to how we see it, when they have gotten
>>into the kernel? I don't see anything wrong with the idea of letting
>>what seems a mostly mature FS into the kernel; that is how most bugs
>>are found in the first place. Of course, there is nothing wrong with
>>putting huge warnings on the FS; I'd recommend them, considering that
>>some people are having funky problems with the patch.
>>
>>
>
>Just unloading some untested code on unsuspecting, innocent users is not
>very nice, is it?
>
>
Christoph is not testing. We have tested, our mailing list has tested.....
> There are lots of reports of ReiserFS 3
>
>filesystems completely destroyed by minor hardware flakiness. And that has
>/never/ been fixed, as the developers just went off to do the "next cool
>thing". That history weighs against ReiserFS, heavily.
>
>
We are supposed to write a filesystem so that overheating CPUs do not
make it crash?
Prejudice is a very simple phenomenom. When either ext3 or ReiserFS V3
crash it is almost always due to bad hardware. Prejudice is the process
of remembering that one filesystem crashed due to bad hardware and not
remembering that the other one crashed.
It is remarkably simple how it works: people who use Reiser4 want it in,
people who use ext3 and don't want to have a choice of something else
don't want it in. That was true of V3, and it is true of V4. My point
of course is that those who have used V4 know more about it than those
who haven't......
I think Alan Cox is the only poster who has no intention of using
Reiser4 but said at one point that he thinks it should go in.
V3 is obsoleted by V4 in every way. V3 is old code that should be
marked as deprecated as soon as V4 has passed mass testing. V4 is far
superior in its coding style also. Having V3 in and V4 out is at this
point just stupid.
This whole thing reminds me of an IBMer who told me that he thought that
IBM lost to MS because they called OS/2 by a name other than DOS. The
sad thing is he was probably right.
V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any
distro or user who would stay with V3 for new installs once we have
passed mass testing is nuts. We need the mass testing.
Hans
From: Alan Cox [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 11:51:21 +0100
On Sul, 2005-09-18 at 22:44 -0700, Hans Reiser wrote:
> We are supposed to write a filesystem so that overheating CPUs do not
> make it crash?
The reverse - and before you lose data.
> I think Alan Cox is the only poster who has no intention of using
> Reiser4 but said at one point that he thinks it should go in.
If its clean enough then yes, like any other fs. Until then no.
From: Alan Cox [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:38:44 +0100
On Sul, 2005-09-18 at 13:22 -0400, michael chang wrote:
> This is exciting to... whom? The only thing that appears remotely
> interesting about it is that it's made by Oracle and apparently is
> supposed to be geared toward parallel server whatsits.
Which no current included fs supports. And parallel file systems btw get
exciting for everyone once you have virtualisation.
> Is that Hans' fault, or the fault of your lot? Why can't we all just get along?
Insufficient drugs ;) ?
> work with. Discriminate him because he's not a developer you can talk
> with, and I believe that's like discriminating a guy in a wheelchair
> because he can't run with you when you jog in the morning.
Hans can learn to work with people, most folks in wheelchairs cannot
take lessons and walk. Many of them have tried months of physiotherapy.
to learn to walk again. I think your comparison is insulting to a lot of
the disabled.
> Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS
> or ext2 or ext3 had never gotten into the kernel. How would their
Linus refused ext3 initially. It went in because it had a userbase,
vendors shipping it and reliable clean code. Saying "no" a lot is really
rather important to keeping the kernel maintainable. I regularly meet
cases we should have said "no" a lot louder 8)
> I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2.
> Indeed, H.264 crashes some computers, similar to Reiser4 might crash
> some machines, but this is merely because Reiser4 explores new
It doesn't matter if reiser4 causes crashes. It matters that people can
fix them, that they are actively fixed and the code is maintainable. It
will have bugs, all complex code has bugs. Hans team have demonstrated
the ability to fix some of those bugs fast, but we also all remember
what happened with reiser3 later on despite early fast fixing.
One big reason we jump up and down so much about the coding style is
that its the one thing that ensures someone else can maintain and fix
code that the author has abandoned, doesn't have time to fix or that
needs access to specific hardware the authors may not have.
Alan
From: Hans Reiser [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Sun, 18 Sep 2005 22:07:18 -0700
Alan Cox wrote:
>
>It doesn't matter if reiser4 causes crashes. It matters that people can
>fix them, that they are actively fixed and the code is maintainable. It
>will have bugs, all complex code has bugs. Hans team have demonstrated
>the ability to fix some of those bugs fast, but we also all remember
>what happened with reiser3 later on despite early fast fixing.
>
>
What was that?
>One big reason we jump up and down so much about the coding style is
>that its the one thing that ensures someone else can maintain and fix
>code that the author has abandoned, doesn't have time to fix or that
>needs access to specific hardware the authors may not have.
>
So why is the code in the kernel so hard to read then?
Linux kernel code is getting better, and Andrew Morton's code is
especially good, but for the most part it's unnecessarily hard to read.
Look at the elevator code for instance. Ugh.
I differ in one major aspect from some. That is, the only coding style
requirement I have of those who work for me is that it must be easy to
read. That is because at every company I can remember where someone was
gungho about advocating that code be written in a specific defined
style, that someone was always the one with the least readable code.
I have a simple punishment for those who violate my requirement: I go
through the code line by line with them, which they always hate for some
reason, and help them comment and clarify it. 1-2 sessions of this, and
they usually change how they code so that they don't have to go through
it again with me.
Asking for readable code is not that different from asking for readable
novels: if you try to define what is required rather than teaching
instance by instance, you can only get in the way of the artist rather
than instructing.
That is why I just say "make it easy to read and I don't care how you do
that so long as it works."
From: Christoph Hellwig [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 10:01:45 +0100
Thanks a lot for the groundless attacks, but I'm done.
I'll stop helping you to review stuff because it's just totally pointless,
you ignore most of the review anyway and start personal attacks.
Please find someone else to review your code for inclusion, that can stand
beeing attacked everytime they write an email. Before you should probably
fix up various bits I wrote up and especialy make sure to get rid of
all duplication of generic I/O code or explain in detail why you need it
and fix your own implementations.
And next time you request review request and inclusion please use nicer
words than 'I request inclusion'. There's no right to get code included
in the kernel tree, it's a honor.
From: Andrew Morton [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 02:21:53 -0700
Christoph Hellwig [email blocked] wrote:
>
> Before you should probably
> fix up various bits I wrote up and especialy make sure to get rid of
> all duplication of generic I/O code or explain in detail why you need it
> and fix your own implementations.
Yup, thanks. I've made a record of your comments in the changelog for
-mm's reiser4-only.patch.
From: Alan Cox [email blocked]
Subject: Re: I request inclusion of reiser4 in the mainline kernel
Date: Mon, 19 Sep 2005 11:43:36 +0100
On Sul, 2005-09-18 at 22:07 -0700, Hans Reiser wrote:
> >the ability to fix some of those bugs fast, but we also all remember
> >what happened with reiser3 later on despite early fast fixing.
> >
> >
> What was that?
Jeff Mahoney added file attributes to reiserfs3, you whined and pointed
people at the yet to be released reiserfs4. Someone fixed the 4K stack
on reiserfs3, you whined. Chris Mason added other fixes like
data=journal support to get some kind of journal feature parity with
ext3, you complained and ask it not to be added.
> That is why I just say "make it easy to read and I don't care how you do
> that so long as it works."
Perhaps you do. The kernel follows a coding style. It isn't my coding
style but like everyone else except you I try and follow it.
Alan
This was also discusses recen
This was also discusses recently and the consensus was that everything in the kernel worked fine with 4K stacks. The only exception being when things were stacked abnormally deep like nfs=>xfs=>lvm=>dm=>scsi.
I don't think I would call that abnormal. Common place? No. Abnormal? No. If you remove "dm" from the list, I would consider that to be a fairly typical server configuration. After all, that would be a SCSI server with LVM that has partitions formated with XFS and exported via NFS. That's run of the mill type stuff right there.
I don't think I would call th
And the point is that a lot of the time even with all of those layers the call chains fit within 4K stacks so if you remove one of them from the mix the call chains are definitely short enough to fit within 4K stacks.
I learned this in kindergarten:
Before anyone says anything else, each kernel developer - come up with 5 nice things to say about the other! ;-)
Seriously, it will help.
disappointing
The dialog is just disappointing, and how long it has gone on is even more disappointing. I'd swear that some of the developers are 13 years old if I didn't know better. There are so many scary comments in the emails going back and forth. Most of all is the evidence that not only does power corrupt, but so does the perception of power.
Every developer is expendable. Just because you think you are right, doesn't make you right. The crap about it being an honor to be considered for inclusion in the kernel is either laughable or really scary.
Yes everyone appreciates the work of developers, but no one appreciates the attitude. If you don't enjoy doing it then get out. Someone will take your place, your code will go away, or something better will take it's place. Regardless, no one, including Linus himself (sorry to use you as an example) is critical to the long term survival of the Linux kernel, whereas a few immature people with bad attitudes can have serious negative consequences.
I do see the argument about Reiser4 as more political and more about egos than anything. Some of the changes requested are reasonable, but I definitely agree that there is plenty of near useless crap in the kernel that is of much less worth than the Reiser4 code. No that doesn't negate the importance of the requested improvements, but it does negate the argument that reiser4 is left out for this reason.
When has inclusion of anything in the kernel, sanctioned it as safe in every situation and flawless in every regard? I've looked at a lot of kernel code, although admittedly I'm not a programmer, and even I can tell there's tons of garbage code in there. The compiler errors alone point to how much isn't maintained, let alone any close examination of anything such as documentation or commenting.
As Hans points out, Reiser3 is really deprecated by Reiser4, and it would be a reasonable tradeoff to just drop it after a bit of mainline testing with R4. If you guys want to continue with the political and egotistical arguing, fine, please just do it after Reiser4 has been put in the kernel.
"As Hans points out, Reiser3
"As Hans points out, Reiser3 is really deprecated by Reiser4, and it would be a reasonable tradeoff to just drop it after a bit of mainline testing with R4."
Deprecated !?
This is a filesystem not an IM client! The only way a filesystem gets deprecated by a newer version is if the new version is *completely* backwards compatible (ext2/3). And even then you give it a couple of years.
Reiser4 is a completely new and different beast from Reiser3, no matter the similarity in the names.
Moving on. Reiser4 does some strange/different, some questionable and some bad things in it's code (judged by Linux VFS coding guidelines). That is without touching on CodingStyle problems. If Hans wants Reiser4 in the mainline kernel he will have to (at minimum) change the bad, and justify the questionable; then people will be willing to work with him.
His current abrasive style (especially contrasted with that of his developers/employees) is doing him no favours. Christoph's email included at least 3 items I can agree with without consulting the code! I suspect many developers are just adding Hans to a mental /ignore list. Which is a shame, because he just may know something about the future of filesystems.
Follow the coding style or fork the kernel or...
If what is said about reiser4's coding style is true, then I think reiser4 should not be included in the kernel. Would you prefer Linux to be written in the same style for every source file, or would you prefer to use 4 spaces for one, tabs for another, etc?
I have written a kernel module, but I don't plan on submitting a patch (but it's GPL, and freely distributed), so I don't have to follow the coding style. If I had intended to submit a patch, I would have read Documentation/CodingStyle thoroughly and followed it.
For small open source utilities, usually if I don't like the original coding style then I will fork it (and change the coding style altogether). But I won't do it with a kernel -- it's just too big.
The conclusion is, it's Linus' kernel, follow _his_ coding style . (and rules, regulations, whatever)
I agree, for whatever reason
I agree, for whatever reason Hans seems entirely opposed to even considering changing his code to match the kernel's stated and well known coding style. This is a requirement of ALL of the code going into the kernel, I don't get why Hans thinks he should have special exclusion from this standard.
I like reiserFS and would love to see reiser4, but Hans needs to get over the "I spent X amount of hours on this and you didn't, so you should all do what I tell you" attitude.
agreed
re: Hans vs Christoph flamewar
OK - I'm no developer, I'm no kernel developer. What I see here are several things:
1. Hans is well and truly aware of the kernel comment and coding requirements, but does NOT want to play by these rules.
2. Christoph, whilst he might be abrasive (and as others have pointed out, so is Hans), has EVERY right to not seek to recommend inclusion of the ReiserFS code if it doesn't conform to the standards for kernel inclusion. Hans has two options - change his coding method to make sure it does comply with Kernel coding requirements and have the code accepted into the kernel tree with a minimum of fuss, or not elect to have the code included. It's his choice. As Alan [Cox] said, the kernel coding/commenting "laws" aren't his cup of tea, but he still complies. I see no reason why Hans, or anyone else, no matter how good the technology should have a dummy spit and then get away with it.
My personal thought is good on Christoph for standing up to Hans. I read the emails above and wasn't impressed with either of them, but - Hans has brought a lot of this ill wind on himself imho.
On another level, I've never been impressed with the reliability or stability of ReiserFS and will not use it as a file system. Period. If others want to do it, sure, go for it. If you want it in the kernel, then stop bitching about it not being included. Go friggen patch it in yourself. Or shut up. There are rules for kernel inclusion, if Hans/Namesys/ReiserFS aren't going to comply, tough shit. Hans well and truly knew what the "rules" were for Kernel inclusion, and chose to ignore it, and is now like the boy crying wolf. I have no pity for him, he bought this on himself.
As to those complaining about losing something in terms of GPL code going into the kernel etc, you're not. Just cos it's not in the kernel doesn't mean you can't go and grab the src code and compile it yourself. If you want to be lazy, fine. But don't bitch to the kernel maintainers when you don't get what you want. As a user, you don't really have any rights [in my eyes] to bitch about the code not being included. If you really want it that much, grab the ReiserFS 4 src code, and fix it yourself and send it Christoph's way.
I only hope that Linus and Andrew use some commonsense here and back Christoph up, because otherwise, we're going to have other developers who contribute code to the kernel doing "Hans dummyspits" about the coding, and kernel code will end up being a fragmented mess.
Dave
Not to say I disagree with yo
Not to say I disagree with your comments, but how exactly is Hans like "the boy crying wolf"? Is your recollection of the moral behind that parable different than mine? I thought it was something about the effects of raising false alarms.
re: Boy who cried wolf
Yes, the usual meaning for that term is crying false alarms, however I have heard it also being interpreted as being "whinging a lot for no real reason". That is the context that I meant it in.
Dave
Cross purposes
I wonder how all this would've panned out if namesys had talked over proposed changes with the VFS maintainers, and tried to get the VFS API adjusted to make room for them. If they'd avoided the "we'll do it all then just drop it on you" approach in favour of trickle-merging supporting code, generalising existing code rather than duplicating it, etc. Now, perhaps the VFS folks really are dead-set on a "nothing but POSIX" rule - but looking at xattrs, SELinux labels, etc, I'm disinclined to think so. They do seem to be quite justifiably concerned that any API changes be viable in the long term, though, since we'll be stuck with them for some time.
I'm as excited about the potential of reiser4 as the next guy, but I see things from a maintainer's perspective. Coding style is important. The ability to communicate with someone who will be maintaining the code is important. Respect for each others' opinions is important. Code that fits into the rest of the codebase, rather than operating as a walled-off section, is important. Modularity is good; copying other modules into yours and hacking them rather than generalising the existing modules to provide the services you need is not, and results in a maintainance nightmare.
My personal experience suggests that ext3 is much more robust than reiserfs in the case of hardware faults. Anybody who claims the solution to this is "don't use bad hardware" most likely lacks experience. Hardware fails. RAID controllers fail; you get double-disk faults, damage from cooling failures, memory errors can happen even with ECC and ChipKill, etc. Any normal FS couldn't be expected to survive these undamaged - that's a pretty insane requirement that'd no doubt come with crippling overhead in sanity checks and redundancy - but it should try to be recoverable. I suspect the difference in this regard is as much as anything ext3's that fsck is much smarter and more robust, where reiserfs's is a sad never-really-finished afterthought.
As for the argument its self, there are so many weird points here where people are talking entirely at cross purposes that it's quite silly. There are things in that conversation that make as much sense as:
"Your shirt is blue ... our uniform is green shirts. You don't have to like it, that's just how we do it, in accordance with our needs. Since you are asking us for something, that is what matters."
"But blue is better! I'm pretty in blue! You're wrong to want green, and you should let me just wear blue."
A coding style, for example, is different to well structured and commented code. It is not valid to say that you shouldn't have to follow the coding style because your code is better documented. You still need to follow the style of the main codebase, for maintainability of the codebase as a whole.
Similarly, "it's fast" doesn't justify potential maintainance costs. v4 isn't a drop-in replacement for v3 unless it can mount v3 and convert it. Gah. There's also enough evidence that v3 got merged then largely dropped that I can understand concerns that the same will happen with v4. After all, they have v5 all planned out... and that's the potential for a lot of legacy baggage to maintain.
To be honest, though, it looks like half the fuss is personal issues and communication. Someone's done a huge amount of work on something that's obviously "their baby", with little or no consultation with the kernel team as they go. They then try to get it merged, frequently telling the kernel folks that their work is crap, or that yours is obviously better because it's faster. That's just not the way to proceed. The kernel team respond by getting pissed off, and picking on small details as well as major issues.
It's unfortunate that nobody in the reiserfs camp seems to have stepped up as a mediator to help smooth the discussion into something constructive. So far it looks like without that, this will never go anywhere.
--
Craig Ringer
fsck's
Reiserfs is an amorphous pile of balanced tree nodes stored with little or no structure on disk (there is a superblock which points to the root of the tree, and some bitmaps for free space, but otherwise any given sector could contain user data, metadata, or both).
One of the reasons why ReiserFS is so fast at filesystem operations is that it doesn't have to waste time moving disk heads from place to place just because inodes are stored in one area while file data is in another--Reiser3 was a reasonable first attempt, and I gather Reiser4 really nailed the idea of having total freedom to write updated filesystem metadata anywhere space was available, instead of being constrained to write it in the same location from which it was read.
On the other hand, Reiser3 always suffered from poor performance when it came to huge files since it was never optimized for a world where the user does one open() and then spends a week working from the file descriptor.
All this flexibility comes with a price: If anything goes non-trivially wrong, reiserfsck has to rebuild this tree by looking though the disk, node by node, and reassembling the entire tree starting from the root. You can misplace a lot of data by destroying a few interior nodes of this tree, and the only way to repair is to search the entire filesystem and deduce--by elimination--which parts of the tree you lost. reiserfsck consumes the old tree and writes a new tree in the same place. (I'm simplifying as I go here, hopefully I didn't simplify so much that it's now wrong. ;-)
Contrast with ext3, where you know whether any given block is an inode, bitmap, or user data, by doing some math on the block address. This makes unintentional damage difficult because you have to clobber each and every file you want to make inaccessible individually. Objects on disk never move once created, so data errors do not match data access patterns and physically adjacent but unused objects are often not harmed. There is never ambiguity whether a given sector contains filesystem metadata or user data.
This simplicity comes with a price--ext3 is damn slow at filesystem operations, and you have to give up almost 3% of your disk to inode tables unless you tweak the default mkfs options. On the other hand, if all you do with your filesystem is open one file and work with that file descriptor for weeks, then ext3 has screaming fast large-file I/O performance. ;-)
Consider what happens when a page is corrupted. In ext3, that page might contain a handful of files that are physically nearby each other. Perhaps these are a few files in /lib that came from the same package and were allocated adjacent inode and block numbers. If you are only reading these files, the likelihood of data damage is small with ext3, unless the atime update trashes the inodes. In reiserfs, what tends to happen is that the directory in /lib, as well as the inodes of the files in /lib, as well as some parts of the files in /lib, as well as various other files in /usr and /etc, all end up being flushed in the same page, because the atimes on all the inodes are modified by the same event (e.g. your system booting up). This seems to be an intentional feature of Reiser4, since the Namesys pages point out the lack of it as a limitation of Reiser3.
The result of this is that, given a specific random data corruption event, ext3 might lose a few files that are physically close together, but the chances are good that you only care about a handful of them, and the damage is therefore limited; however, reiserfs might lose the specific set of files that you used consecutively last time your system booted, and almost nothing else. I've lost count of the number of times I've seen the latter failure mode.
Does this mean ext3 is better? No, ext3 is quite slow and cannot use space efficiently when the rest of the system is working properly, and neither ext3 nor reiserfs provides any recovery capability when the rest of the system is not working properly. Does this mean reiserfs is better? No, all things being equal, in the statistical average case, you'll lose more data per data corruption event with reiserfs, and it's harder to recover a reiserfs once it is damaged.
In my experience both ext3 and reiserfs are quite robust against non-corrupting failures like power loss and kernel hangs, and the need to do fsck on either is almost always due to a problem with specific hardware, or a really lame kernel bug.
What's the real problem? The problem is that data is being lost. By the time you're wondering whether one filesystem's fsck is better than another's, it's too late--your data is already gone. The solution? Don't lose the data: keep backups, use RAID, use data integrity verification at every level from disk firmware up to application level, test all sectors on all your disks every day.
You're right, _but_...
I recently gave another try to Reiser4 - I am a strong reiser4 believer and I was amazed by its' performance from the first moment I've seen it.
The last time ended badly - i lost some data, most files ended in /lost+found named after inodes(?), I simply had to reinstall. But what the hell, it was yound, it was fast, and it just got included in -mm (where most things tend to break occassionaly).
Now I've tried again - about 9 months after that. Created the fs, put all data and whoooooooooooom, it flew like never before. I was happy, system was happy.
Then one day, when playing a movie, it suddenly paused for a minute doing nothing. I've seen it before and suspected a hard drive failure or interrupt badness.
But when i fired up `dmesg`, there were tons of messages from reiser4fs like: nikita too many iterations 65535.
Nothing looking like a real error, just a stuck loop, all files were readable and I ignored it silently.
The next day, same thing occured with numerous files, I was a little worried, but everything could still be read at the expense of whole system pausing to make space for reiser4's iteration things. A minute later, reiser4 oops()ed.
At this point, I prepared a reiser4-livecd and ran fsck. It ran for a few minutes and complained about some stuff that needs to get fixed with "--build-fs". Having experience from my 9 months old try, I planned to the the backup first, but it proved impossible. On certain files, the kernel oopsed. I also started getting messages like "filesystem has errors, forcing read-only mount" which was promptly corrected by "remounting filesystem read-only" - so I guess the force thing was just to scare me and has a reminder "finish me!" somewhere deep in code.
It got worse and worse, now it was impossible to write anything to disk - everytime something got flushed, kernel oopsed. And there was no way to force a read-only mount because there was no way to write it to the disk...
sync hang the system and oopsed in the end.
So I carefuly backed up the few important files I have and ran fsck --build-fs on my / partition.
It finished in a few minutes and put just a few files in lost+found (i identified it as a few temp files probably). So I boot from the partition again "filesystem has errors, forcing read-only mount" greeted me again and all the errors where still here.
Wtf?
So another reboot, anouther fsck --build-fs run. It "fixed" a few things and printed "FILESYSTEM IS CLEAN" in large friendly letters. Being a little unsure of the result, I immediately ran fsck again. The same errors were still clean - unfixed!
I of course ran badblocks (no errors) and tried another livecd, same result.
I'm back on reiser3 that works.
Please note that I reported the previous error to namesys crew, they got root shell access to the system. And never fixed it. So...
Following the kernel coding s
Following the kernel coding style is easy as running reiser4 through a code beautifier, with the exception of the asserts...
Whats the big deal?
Following the coding style
That's not really true. The coding style encompasses a whole lot more than what can be fixed mechanically by a code beautifier. It encompasses stuff like the idioms used for error handling, the idioms used for traversing data structures, etc. These are hard to fix automatically. Although, given that the FS is a pluggable module and not an integral part of the kernel, I don't see any particular reason to enforce such a level of stylistic restriction upon it.
that's the killer for me
Clearly, this FS is not ready for prime time. I've heard some other anecdotal evidence, but nothing this descriptive.
Thanks for the information,
Greg Metcalfe
What does robustness of v3 have to do with inclusion of V4?
What is the relevance of comparing the robustness of ext3 and reiserfs-V3 on flaky hardware at this point?
Read up on Reiser4 and how it works, before deciding that how reiserfs(v3) behaves on faulty hardware compared to how ext3 or any other FS does, is an important factor to whether
Reiser4 is ready to be incorporated and maintained by the linux kernel developer community.
The topic, as I understand it, is why Reiser4 will not make it into the official 2.6 linux kernel source yet.
Hans: Please respect the kernel maintainers point of view.
I have a feeling they often have a wider perspective.
The linux kernel is used in so many places and on so many different architectures, that I am truly amazed that there are people who really understand how to deal with things in a compatible/portable manner.
The kernel maintainers have reasons for their demands. I believe that the majority of these demands are for the good of the community.
I've been dreaming about Reiser4 for many years now, and I am ready to wait another year if that is what it takes to get it incorporated in the kernel in a way that the kernel maintainers can agree upon.
If Reiser4 conflicts with VFS or simply is too difficult for the kernel developers to fully understand, then fine, let it live as a set of patches, and be clear about what conflicting parts of the kernel that it breaks.
From what I read here and on the lkml it looks like Cristoph has a good understanding of what Reiser4 is all about, and has very reasonable requirements for what needs to be done to the Reiser4 source prior to a real code-review before inclusion in the mainline kernel tree.
I don't understand why Hans so stubbornly refuses to follow the accepted idioms and calling conventions and so on at this point.
Wouldn't it be much easier for him and his programmers if their source looked the same as the rest of the kernel? Easier for _them_also_ to maintain?
Please please Hans:
swallow your pride,
take a bite of the sour apple,
crawl to the crucifix,
and get started on porting reiser4 to linux coding standards.
Fix the parts of the linux kernel apis that are not optimally implemented and use them instead of rolling your own (make the rest of the kernel use your functions)
We want Reiser4!
Pretty please with sugar on top?
All out Death match
Let's cut the crap folks. Most of you that take sides are a bunch of gutless wimps in the real world. This is a pissing contest extraordinaire. I and the millions of other Linux enthusiasts could give two shits to the wind about some "right of passage" or "right of succession" required to get code built into the kernel.
None of you are fessing up to the fact that Programming is an Art. Let me know when it becomes as grounded as Mechanical Engineering and you might be able to then stop metaphorically whipping your dicks out and get back to the focus.
You love Linux development not just for the "purity" bullshit of "better code" or the "aesthetic beauty" of a certain style of code/formatting of said code--you loved the idea of telling establishment to piss off and banded together enough under your pirate flag to make a dent into an industry that treated many of you like monkeys.
Most of you were never popular in social circles as kids and by the kernel mailing list diatribes are even more pathetic, social miscreants as adults.
The comment referencing diplomacy is truly lacking in the sandbox of adults who are still mostly all in diapers: clean your drawers its beginning to stink up the beach already.
Reiser4 very slow
I just compiled a reiser4-enabled kernel. kernel 2.6.15-rc5 patched with
ckpp patchset (which has reiser4 from mm, see http://ckpp.tuxfamily.org). The result is a painfully slow kernel. BTW, applying archck5 (see http://iphitus.loudas.com/archck.php) on 2.6.14 results instead in a quite fast kernel.
Reiser 4 in Kernel
There are so many other things in the kernel besides just FS support. As much as I honestly want to see the Reiser support there, I also understand that there must be some code consistency across all the drivers in order to get it into the kernel source.
There's really no need for all of us to waste time flaming and trying to come up with something smart to say in retort to each other. If the code is consistent, run wit it... or else one of these days someone is going to kill someone.
But anyways, on that note, I'd like to see the NVIDIA drivers in there too... hmm