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
Reiser3 or Reiser4?
Reiser3 or Reiser4?