The discussion about why the Reiser4 filesystem has not been merged into the Linux kernel [story] continues on the lkml. Hans Reiser [interview] contrasted the struggles Reiser4 has had trying to get merged versus recent discussion about the up and coming ext4 filesystem [story], "the code isn't even written, benchmarked, or tested yet, and it is going into the kernel already so that its developers don't have to deal with maintaining patches separate from the tree. Wow. Kind of hard to argue that it is not politically differentiated, isn't it?"

Theodore T'so responsed, "it is a development procedure that was developed after discussion and consensus building across LKML and the ext2/3/4 development team. It was not the original plan put forth by the ext2 developers, but after listening to the concerns and suggestions, we did not question the motives of the people making suggestions; we listened." He went on to note that parts of what will be ext4 were written a year ago, and have been heavily tested and reviewed. Others pointed out that the evolution between ext3 and ext4 will be a very public process, with patches being merged gradually, whereas Reiser4 is a completely different code base from Reiser3.

The latest chapter in this ongoing debate tends to be more about clashing personalities than the code in question. How this affects if and when the Reiser4 filesystem will be merged into the mainline Linux kernel is yet to be seen.

From: Hans Reiser [email blocked]
To: LKML [email blocked]
Subject: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Fri, 21 Jul 2006 13:46:18 -0600

Is http://wiki.kernelnewbies.org/WhyReiser4IsNotIn truly the "official"
point of view as claimed by its author?  An interesting method of
expression for it.  I heard about it from a user who suggested that I
respond before it got slashdotted.

Let me ask that one compare and contrast the ext4 integration procedure
outlined by Ted Tso, with the procedure experienced by other
filesystems.  The code isn't even written, benchmarked, or tested yet,
and it is going into the kernel already so that its developers don't
have to deal with maintaining patches separate from the tree.  Wow. 
Kind of hard to argue that it is not politically differentiated, isn't it?

Consider what happened with XFS as the article writer mentions.  I met
the original XFS team, led by two very senior developers (Jim Grey, and
another fellow whose name I am blanking on, forgive me, I learned much
from him in just a few conversations).  They were kind enough to
instruct me on what ideas I should take from XFS, and you know what, I
listened.  Reiser4's allocate on flush is the result of their kind
instruction.  I then took it a bit further, like a good student, and
Reiser4 also has balance on flush, compress on flush, etc.

These guys wanted to port XFS to Linux, but there was a problem, which
was that IRIX was better in some ways than Linux, and XFS depended on
those advantages.  Now I met them, and I have to tell you that it was
pretty obvious that these guys knew what they were doing.  Suggest that
these guys needed supervision --- sorry, no way, we needed their
supervision.  What happened?  They got hassled.  Instead of learning
from them, welcoming into our community two very senior developers who
knew a lot more than any of us about the topics they chose to speak
about, they got hassled, they get ignored, they felt rejected, and left
the Linux community forever, never to return.  XFS is still with us, but
the loss of those two could only have been devastating for their
project.    I think the whole kernel community suffered from their loss.

Linux has a problem, which is that with success it is attracting people
with more skill than what it started with, and it is not doing a very
good job of handling that.  In fact, it downright stinks at it, behaving
in the worst way it could choose for handling that.  We have lost quite
a number of FS developers who just don't want to deal with people who
know less than they do but are obnoxious and disrespectful to
submissions because they enjoy powertripping.  We lost David Mazieres,
for example, because he is very very bright, is one of DARPA's most
promising security researchers, and he does not want to be bothered with
Viro et al. so he develops for BSD instead.  Linus, if you really want
to prove that Linux welcomes talented people, go sweet talk Mazieres
into giving Linux another try, you might succeed if you try.  The odd
thing is that Viro is not obnoxious at all in person.  lkml suffers from
email disease, and we need to make conscious efforts to reduce that.

Regarding distros accepting filesystems first, that is just completely
backwards from what it ought to be.  Linus, I respect you a lot, but I
know this one is your idea, and some things I disagree with you on. 
Distros are marketed towards people who do not know how to tar and untar
if an FS is dropped.  A reasonable approach would be to say that any
filesystem marked as experimental can be dropped at any time, so if you
aren't able to tar and untar the partition it is on when a new kernel
comes out, you should not use experimental filesystems.  Then most
distros will not make the experimental FS visible to users who don't
press three buttons acknowledging that they were warned....  Linspire's
view is pretty simple, they need to know that Reiser4 will be accepted
BEFORE they make their distro depend on it.  This is being responsible
to their users.  I could go ask Debian, etc., to include Reiser4, but it
is the wrong way, so I am shy about it.

I am not saying that ext4 should not be accepted as an experimental FS,
I don't even really believe that ext4 should only be accepted when it is
higher performance than Reiser4, I am saying that the process should be
the same for everyone.  Reiser4 is the upgrade for ReiserFS V3, in which
we fix all of V3's flaws without disturbing the mission critical servers
using V3 by changing the V3 code underneath them.  (Things like the bug
affecting MythTV users on V3 at the moment just should not be
happening.  Experiments belong in V4, and I wish there was more respect
for my views on this.).  V4 contains bug fixes for several V3 bugs that
are too deep to fix without deep rewrite, and since V3 does not have
plugins, disk format changes should not get added to a stable branch. 
When submitted Reiser4 was more stable than V3 was when it was
accepted.  (This is because we now have a much better test suite.   I
would never submit code that I know has a bug unfixed.  At the moment we
can crash Reiser4 using our test suite, as some of the linux kernel
inclusion related changes made recently were extensive, I hope we have
that bug fixed by next week.)

We should develop a culture in which acceptance is more based on whose
code measurably performs well than on who is friends with whom.  We
should not think that such a culture will develop without an effort
being made to grow it.

Actually, if we just had a few more akpms to go around, things would be
a lot better..... oh well.  We need to recruit more people like him. 
You can't really have code reviewed by persons less experienced and
proven than those being reviewed, it just doesn't work too well.  Linux
needs to look outward more, and welcome persons who have proven
themselves in other arenas as though we were lucky to get their time. 
Because we are.  Maybe when we don't have people with the expertise to
review something, we should go outside the Linux community, like the way
academic journals will solicit outside reviewers for particular articles
as they need them.  Our current attitude resembles that of BSD before it
lost the market to Linux, I remember it well, there was a reason why I
developed for Linux instead.

Avoiding the problems that some large corporations have with politics
does not happen automatically as a result of it being free software, it
requires as much effort as it does in the successful large
corporations.  Non-profits are in no way immune to being harmed by
internal politics.

If it is true that Reiser4 is likely to go in for 2.6.19, this is good
to hear, though an odd source to hear it from.  If it is true, then I
will skip lobbying distros to accept Reiser4 before the kernel does,
because really it makes little sense for them to do so.

Hans



From: Theodore Tso [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sat, 22 Jul 2006 09:02:19 -0400

On Fri, Jul 21, 2006 at 01:46:18PM -0600, Hans Reiser wrote:
> Let me ask that one compare and contrast the ext4 integration procedure
> outlined by Ted Tso

"integration procedure" is hardly an accurate description, rather it
is a development procedure that was developed after discussion and
consensus building across LKML and the ext2/3/4 development team.  It
was not the original plan put forth by the ext2 developers, but after
listening to the concerns and suggestions, we did not question the
motives of the people making suggestions; we listened.

> The code isn't even written, benchmarked, or tested yet,

Actually, the first bits that we plan to merge have already been
written and in use by hundreds of clusterfs customers, posted to LKML
for comments (and we don't attack our reviewers, we thank them for
their comments), and in fact they were written about at last year's
OLS complete with benchmarks and graphs.
(http://ext2.sourceforge.net/2005-ols/2005-ols-ext3.html)

> Consider what happened with XFS as the article writer mentions.  I met
> the original XFS team, led by two very senior developers (Jim Grey, and
> another fellow whose name I am blanking on, forgive me, I learned much
> from him in just a few conversations).  

I believe you are referring to Jim Mostek and Steve Lord, and yes,
they were very talented developers and engineers.  I very much enjoyed
talking to them at various filesystem and Linux conferences and
workshops.

> supervision.  What happened?  They got hassled.  Instead of learning
> from them, welcoming into our community two very senior developers who
> knew a lot more than any of us about the topics they chose to speak
> about, they got hassled, they get ignored, they felt rejected, and left
> the Linux community forever, never to return.  

That's hardly what happened.  SGI went through layoffs, and they were
hit.  See:  http://slashdot.org/articles/01/05/26/0743254.shtml

> A reasonable approach would be to say that any
> filesystem marked as experimental can be dropped at any time, so if you
> aren't able to tar and untar the partition it is on when a new kernel
> comes out, you should not use experimental filesystems.  Then most
> distros will not make the experimental FS visible to users who don't
> press three buttons acknowledging that they were warned....  Linspire's
> view is pretty simple, they need to know that Reiser4 will be accepted
> BEFORE they make their distro depend on it.  

You do realize these two statements are completely contradictory,
don't you?  If an experimental filesystem can be dropped at any time,
then Linspire can't depend on it from the point of view of supporting
their users.  If there is a huge user base, then someone is going to
have to maintain it, even if the developer community has moved on to
supporting the next new exciting filesystem thing.  Hence, it is
critical that the resulting filesystem be fully maintainable before it
is integrated.  To put it in your words, it wouldn't be responsible to
the user base to do otherwise.

							- Ted



From: Hans Reiser [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sat, 22 Jul 2006 12:33:09 -0600

Theodore Tso wrote:

>
>Actually, the first bits
>
yes, the first bits....   other people send in completed filesystems....

> that we plan to merge
>
I don't actually think that your merge approach is the wrong one, I
think that it being exclusive to you is what is wrong.

>
>  
>
>>Consider what happened with XFS as the article writer mentions.  I met
>>the original XFS team, led by two very senior developers (Jim Grey, and
>>another fellow whose name I am blanking on, forgive me, I learned much
>>from him in just a few conversations).  
>>    
>>
>
>I believe you are referring to Jim Mostek
>
Ah, Jim Mostek and Jim Gray.  (Steve Lord was not a senior guy back
then, and he is still with SGI last I heard....  I actually don't know
Steve very well, hmm, maybe some future conference....)  Thanks.

>That's hardly what happened.  SGI went through layoffs, and they were
>hit.  See:  http://slashdot.org/articles/01/05/26/0743254.shtml
>  
>
As the other poster mentioned, they went off to startups, and did not
become part of our community.  How much of that was because their
contributions were more hassled than welcomed, I cannot say with
certainty, I can only say that they were discouraged by the difficulty
of getting their stuff in, and this was not as it should have been. 
They were more knowledgeable than we were on the topics they spoke on,
and this was not recognized and acknowledged.

Outsiders are not respected by the kernel community.  This means we miss
a lot.

>  
>
>>A reasonable approach would be to say that any
>>filesystem marked as experimental can be dropped at any time, so if you
>>aren't able to tar and untar the partition it is on when a new kernel
>>comes out, you should not use experimental filesystems.  Then most
>>distros will not make the experimental FS visible to users who don't
>>press three buttons acknowledging that they were warned....  Linspire's
>>view is pretty simple, they need to know that Reiser4 will be accepted
>>BEFORE they make their distro depend on it.  
>>    
>>
>
>You do realize these two statements are completely contradictory,
>don't you? 
>
No, because distros would wait until it is not experimental before
giving it to their users by default, in my proposed release model.  lkml
is populated with people FAR more suited to experimenting with
experimental filesystems than typical distro customer lists are.  It is
commercial and political reasons that motivate distros being the first
with patches not tried yet by lkml, not the interests of the users.

Now, for other patches these commercial and political reasons may need
to be catered to as the price of getting the Redhats of the world to
fund kernel development, but that logic does not apply to Reiser4's
particulars.

Hans



From: Jeff Garzik [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sat, 22 Jul 2006 16:29:03 -0400

Hans Reiser wrote:
> Theodore Tso wrote:
> 
>> Actually, the first bits
>>
> yes, the first bits....   other people send in completed filesystems....

Completed filesystems have a much higher barrier to entry, because they 
require a fresh review.

ext4 will go upstream MUCH faster, because it follows the standard 
process of Linux evolution, building on top of existing code with 
progressive changes:

	cp -a ext3 ext4
	update ext4
	update ext4
	update ext4
	...

This process builds upon existing reviews and knowledge of existing 
code.  This process also guarantees a higher degree of stability during 
development, because the interim changes must always form a complete, 
working, usable filesystem.


> As the other poster mentioned, they went off to startups, and did not
> become part of our community.  How much of that was because their
> contributions were more hassled than welcomed, I cannot say with
> certainty, I can only say that they were discouraged by the difficulty
> of getting their stuff in, and this was not as it should have been. 
> They were more knowledgeable than we were on the topics they spoke on,
> and this was not recognized and acknowledged.
> 
> Outsiders are not respected by the kernel community.  This means we miss
> a lot.

Anyone who fails to respect the kernel development process, the process 
of building consensus, is turn not respected, flamed, and/or ignored.

If you don't respect us, why should we respect you?


> No, because distros would wait until it is not experimental before
> giving it to their users by default, in my proposed release model.  lkml

Distros follow their own release model, and don't have a care about what 
Hans Reiser thinks they should do.

<vendor hat on>
Red Hat has a pipeline in place for offering new technologies to users: 
  Fedora Core -> RHEL, and sometimes RHEL technology previews.  SuSE 
presumably does something similar with OpenSUSE.
</vendor hat>

There is PLENTY of opportunity to be experimental.


> is populated with people FAR more suited to experimenting with
> experimental filesystems than typical distro customer lists are.  It is
> commercial and political reasons that motivate distros being the first
> with patches not tried yet by lkml, not the interests of the users.

> Now, for other patches these commercial and political reasons may need
> to be catered to as the price of getting the Redhats of the world to
> fund kernel development, but that logic does not apply to Reiser4's
> particulars.

I always feel sad to hear technologists wail about politics.

In my experience, the cause of such is almost always the fault of the 
submittor, ignoring consensus.  But once the submittor has decided that 
"politics" are cause of their troubles, the submittor focuses on that 
rather than addressing the technology objections that were raised.

With you in particular, you demonstrated NO interest in maintaining 
reiser3, once reiser4 began to make a splash.  Linux kernel code exists 
for DECADES, and as such, long term maintenance is a CRITICAL aspect of 
development.

Regardless of whatever new whiz-bang technology exists in reiser4, there 
is a very real worry that you will abandon reiser4 once its in the tree 
for a few years, just like what happened with reiser3.

	Jeff



From: Hans Reiser [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 01:20:40 -0600

Jeff, I think that a large part of what is going on is that any patch
that can be read in 15 minutes gets reviewed immediately, and any patch
that is worked on for 5 years and then takes a week to read gets
neglected.  This is true even if line for line the 1 week to read patch
is more valuable.    What is more is that people know this is
irrational, but aren't able to cure it in themselves.  Even I have a
problem of paying too much attention to endless 5 minute emails when I
know I should instead, say, read the compression plugin from beginning
to end.

There is nothing about small patches that makes them better code.  There
is no reason we should favor them, if the developers are willing to work
on something for 5 years to escape a local optimum, that is often the
RIGHT thing to do.

It is importand that we embrace our diversity, and be happy for the
strength it gives us.  Some of us are good at small patches that evolve,
and some are good at escaping local optimums.  We all have value, both
trees and grass have their place in the world.


>
>
> With you in particular, you demonstrated NO interest in maintaining
> reiser3, once reiser4 began to make a splash.  Linux kernel code
> exists for DECADES, and as such, long term maintenance is a CRITICAL
> aspect of development.

You are rejecting the development model which is based on stable
branches getting only bugfixes.  V3 is a stable branch.  It just had a
feature added to it which added a bug that MythTV users are hitting. 
Some of them are responding to it by walking away from Reiser3, and no
doubt muttering about what an unstable pile of shit our code is.  On
monday one of my guys is stopping work on V4 to send in a bug fix for a
feature that should have gone into V4 first, and then maybe gotten
backported after it was proven in V4.

So, given that Jeff and Chris can often be gotten to fix bugs, do I ask
them to do it whenever there is a bug to fix and they will fix it?  Oh
yes!  The despiriting thing though is that there is usually another
reason to let them fix it, which is that almost all v3 bugs are in
features they have added to what ought to have been a stable branch, and
since it is their code, they should be the ones to fix it.  We might,
maybe, get one bug report a year in code written by Namesys before  I
announced code freeze on V3.

I just got an email from the programmer who wrote the MythTV bug saying
that he is just too busy to bother fixing the bug in his code.....  so
my response is that a Namesys programmer is going to fix it on Monday.

All this talk about how you guys worry that code is going to be
abandoned, you know, try policing the kids in their 20's who do it, not
those who have been working since 1984 on developing the thing you
somehow are worried they will abandon.  I am not 20 something anymore, I
am getting fat no matter how much I exercise, and I stick with things,
and I only wish some things didn't stick so much with my middle....

>
> Regardless of whatever new whiz-bang technology exists in reiser4,
> there is a very real worry that you will abandon reiser4 once its in
> the tree for a few years, just like what happened with reiser3.

And look at how Linus abandoned 2.4!  Users of 2.4 needed so many
features that were put into 2.6 instead, and they were just abandoned
and neglected and....  Do you think he will abandon 2.6.18 also?

The stable branch of code getting only bugfixes and the development
branch getting all the new features model of development is something
most release management professionals agree is the right way to do
things.  I worked with release management teams some, and I have to say
that the dominant paradigm in the software industry is, in this case,
the best one yet.

Of course, I want to make it a little better, you know how I am, and as
I was just discussing on the reiserfs-list, with plugins we can now move
to a model in which if you mount reiser4 using the -o reiser4.1-beta
mount option, it changes what the default plugin is, and that is how we
do releases, we put our beta code in different plugins, and let the user
choose whether to upgrade to a new release by just choosing what plugins
to use as his default.  Now that we paid the 5 year development price
tag to get everything as plugins, we can now upgrade in littler pieces
than any other FS.  Hmm, I need a buzz phrase, its not extreme
programming, maybe "moderate programming".  Does that sound exciting to
others.;-)  Seriously though, I am curious to see whether plugin based
release management works out as pleasantly for users as I am hoping it will.

Hans



From: Matt Heler [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 02:12:54 -0700

On Sunday 23 July 2006 12:20 am, Hans Reiser wrote:
> I just got an email from the programmer who wrote the MythTV bug saying
> that he is just too busy to bother fixing the bug in his code.....  so
> my response is that a Namesys programmer is going to fix it on Monday.

The way you wrote this, makes it sound like a userspace issue, and _not_ a 
problem with reiserfs.

> And look at how Linus abandoned 2.4!  Users of 2.4 needed so many
> features that were put into 2.6 instead, and they were just abandoned
> and neglected and....  Do you think he will abandon 2.6.18 also?

Not entirely true, he did not abandon the 2.4 kernel branch, he passed on 
maintainership to Marcelo. Similar to how he passed the torch on the 2.2 
kernel branch to Alan Cox. Also on a side note, many new features ( and a ton 
of bug fixes !! ) were added to the 2.4 series _after_ Linus started working 
on the 2.5 branch.



From: Hans Reiser [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 22:01:38 -0600

Matt Heler wrote:

>On Sunday 23 July 2006 12:20 am, Hans Reiser wrote:
>  
>
>
>The way you wrote this, makes it sound like a userspace issue, and _not_ a 
>problem with reiserfs.
>  
>
It was a problem with reiserfs.  Code was added to search for the
perfect spot to fit a file.  If there is no perfect spot, it searches
every bitmap for that spot before giving up.  However, Jeff kindly gave
us a little patch to fix this and made the whole issue moot.  It also
seems I was in error, and we actually have had this problem since 2002. 
Now some past remarks from users about fragmentation make more sense. 
What can I say, since I have no MP3s I never get anywhere near full on
my personal hard drive.

>  
>
>>And look at how Linus abandoned 2.4!  Users of 2.4 needed so many
>>features that were put into 2.6 instead, and they were just abandoned
>>and neglected and....  Do you think he will abandon 2.6.18 also?
>>    
>>
>
>Not entirely true, he did not abandon the 2.4 kernel branch, he passed on 
>maintainership to Marcelo. Similar to how he passed the torch on the 2.2 
>kernel branch to Alan Cox. Also on a side note, many new features ( and a ton 
>of bug fixes !! ) were added to the 2.4 series _after_ Linus started working 
>on the 2.5 branch.
>  
>
You missed the sarcasm in my voice, my apologies, it is the trouble I
have with email.

Just to balance everything with some nuance, let me add that when a
development branch is first opened, there is usually a bit of gray as to
whether particular small features should go into the development branch
or the stable branch.  As the stable branch gets more stable the
incentive to not destabilize it increases, and as a development branch
becomes usable, the delay to users due to putting features only there
reduces.

I want reiserfs to be the filesystem that professional system
administrators view as the one with both the fastest technological pace,
and the most conservative release management.

I apologize to users  that the technology required a 5 year gap between
releases.   It just did, an outsider may not realize how deep the
changes we made were.  Things like per node locking based on a whole new
approach to tree locking that goes bottom up instead of the usual top
down are big tasks.    Dancing trees are a big change, getting rid of
blobs is a big change, wandering logs.....  We did a lot of things like
that, and got very fortunate with them.  If we had tried to add such
changes to V3, the code would have been unstable the whole 5 years, and
would not have come out right.

Experienced writers know that often, if you want to fix a passage, even
a passage that is quite good in some parts, sometimes it is better to
write the whole passage again without looking at the text of the first
draft of the old passage, because sometimes your muse just needs the
freedom, and without the freedom the awkwardness of the old passage is
incurable.  Probably there is some very sophisticated neurological
reason why that is.  Code can be the same.  Sometimes.  I knew that
reiser4 HAD to be written from scratch without reference to the old code
if it was to come out right. 

If I cannot be a great artist, at least I can try to have the
temperament of one, yes? :-)

I sincerely hope that using mount options to select default plugins, and
making development code go into new plugins means that releases after
this can be roughly quarterly, and that we can start doing a whole bunch
of quick little plugins.  Technically, I think it is going to be
downhill skiing from here, and some very visible bits of functionality
will get added much more easily than this difficult infrastructure we
just coded.

Hans


From: Jeff Mahoney [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 16:46:57 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:
> I just got an email from the programmer who wrote the MythTV bug saying
> that he is just too busy to bother fixing the bug in his code.....  so
> my response is that a Namesys programmer is going to fix it on Monday.


Hans -

I'll accept blame when it's my bug, but the MythTV one isn't. I've been
working with the bitmap code and did the analysis to track down what was
happening, but that doesn't make it a bug in my code.

That particular bug isn't in the bitmap scanning code, it's a side
effect of the write batching higher up. It's looking for a window of 32
blocks, and there's just no window that large available. It ends up
scanning all the bitmaps looking for the window, and then backs off to
single block allocations. The scanning code works fine, and it does skip
where there aren't enough free blocks available in a particular bitmap.

It's a pathological case when the file system is seriously fragmented. A
quick fix would be to set a flag indicating that future writes shouldn't
bother trying to find a window that large, but that's a hack. A better
allocation algorithm would keep track of free space extents in memory,
subject to getting dropped by memory pressure. Since that information
would be separate from the bitmaps themselves, we could get rid of that
nasty "is this block free, but in the journal?" check that we need to do
as well. It's invasive, and a quicker fix would just be to track the
largest window, and rescan when it gets used or a block in that bitmap
gets freed.

That said, I actually did start work on a fix for this one, but I really
just don't have the time right now.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEw+BBLPWxlyuTD7IRAtG8AKCOWW/AH3NAen6gd6BToJGVfzdnNACfYkVS
j2/6yAAeWKAhs4ng9fdGW0Y=
=gB+v
-----END PGP SIGNATURE-----



From: Hans Reiser [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 15:15:26 -0600

Jeff Mahoney wrote:

>
>
> That particular bug isn't in the bitmap scanning code, it's a side
> effect of the write batching higher up.

Did you write the code that looks for a window of 32
blocks?  If not, and if this code has been around for a long time, I
apologize.   I thought you did write it and added it in recent months.

>
>
> It's a pathological case when the file system is seriously fragmented.

Most bugs are pathological cases.;-)

> A
> quick fix would be to set a flag indicating that future writes shouldn't
> bother trying to find a window that large,

There are lots of quick fixes.  1) The quickest is to not scan for the
window at all.  2) The second quickest is to limit the number of bitmaps
that will be scanned to some number like 3.  3) The not at all quickest
is to track free extents like XFS does, which is not a hack, but it
belongs in a development branch.  I am not sure it is worth the
complexity, but my mind is not closed.

On monday we will do 1) or 2), probably 1).   After the repacker is
done, we should review all our block allocation algorithms.  I have an
idea for how to do things more optimally for streaming media that will
avoid fragmentation over time, and when combined with the repacker may
make 3 not worthwhile.

I am grateful that you and Chris do bug fixes, but when you guys are too
busy, (and that can and will happen to any of us), the baton needs to
get passed.  V3 needs to be a zero defect product, and once we know it
is a bug I don't want bugs in V3 to remain unfixed for more than a day
plus the time it takes to fix it.    If you do add code, I want any bugs
that show up in the aftermath of mainstream merging to get jumped on.

Hans



From: Jeff Mahoney [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 19:22:49 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:
> Jeff Mahoney wrote:
> 
>>
>> That particular bug isn't in the bitmap scanning code, it's a side
>> effect of the write batching higher up.
> 
> Did you write the code that looks for a window of 32
> blocks?  If not, and if this code has been around for a long time, I
> apologize.   I thought you did write it and added it in recent months.

Nope. The scan_bitmap_block() code that looks for windows was added in
a changeset from a bk merge against 2.5.33 in September 2002. The change
to want a minimum size window was added in June 2004 to 2.6.8-rc2. That
patch is actually credited to both Mason and I, but I don't recall who
wrote that bit. It may well have been my code, after all, but it's
certainly not a new bug. *shrug* I guess MythTV might just be generating
an i/o pattern that hadn't been seen before.

>> A
>> quick fix would be to set a flag indicating that future writes shouldn't
>> bother trying to find a window that large,
> 
> There are lots of quick fixes.  1) The quickest is to not scan for the
> window at all.  2) The second quickest is to limit the number of bitmaps
> that will be scanned to some number like 3.  3) The not at all quickest
> is to track free extents like XFS does, which is not a hack, but it
> belongs in a development branch.  I am not sure it is worth the
> complexity, but my mind is not closed.
> 
> On monday we will do 1) or 2), probably 1).   After the repacker is
> done, we should review all our block allocation algorithms.  I have an
> idea for how to do things more optimally for streaming media that will
> avoid fragmentation over time, and when combined with the repacker may
> make 3 not worthwhile.

If you want to go the 1) route, it's trivial. See patch below. It will
restore the one-block-at-a-time behavior.

> I am grateful that you and Chris do bug fixes, but when you guys are too
> busy, (and that can and will happen to any of us), the baton needs to
> get passed.  V3 needs to be a zero defect product, and once we know it
> is a bug I don't want bugs in V3 to remain unfixed for more than a day
> plus the time it takes to fix it.    If you do add code, I want any bugs
> that show up in the aftermath of mainstream merging to get jumped on.

Anyone up for it? :) There are changes I'd like to see in reiser3,
particularly ones that address the severe problems observed in David
Chinner's high bandwidth file system talk this year at OLS. Specifically,
it ended up making very little progress and spending the majority of the
time in the journal when the workload is streaming data at the disk at a
very high rate on a very large file system. Yes, that is certainly XFS's
sweet spot, but barely making progress at all is a bit more severe than
"poor performance." Perhaps mkreiserfs should be a bit saner about choosing
journal sizes, since a 32 MB journal is not a good fit for all cases. Also,
I'd like to see the usage of the BKL gone as it severely limits performance
when more than one thread is writing to the file system, or even another
reiserfs file system. It's not entirely low hanging fruit since the nested
cases need to be audited, but it shouldn't be too hard to eliminate the
inter-filesystem lock contention by replacing the BKL with a per-sb mutex.
I have some more things, but I have nowhere near the time to do them,
and other file systems will perform fine.

- -Jeff

Patch:

- --- linux-2.6.17.orig/fs/reiserfs/bitmap.c	2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.17.orig.devel/fs/reiserfs/bitmap.c	2006-07-23 19:10:57.000000000 -0400
@@ -1020,7 +1020,6 @@
 	b_blocknr_t finish = SB_BLOCK_COUNT(s) - 1;
 	int passno = 0;
 	int nr_allocated = 0;
- -	int bigalloc = 0;
 
 	determine_prealloc_size(hint);
 	if (!hint->formatted_node) {
@@ -1047,28 +1046,9 @@
 				hint->preallocate = hint->prealloc_size = 0;
 		}
 		/* for unformatted nodes, force large allocations */
- -		bigalloc = amount_needed;
 	}
 
 	do {
- -		/* in bigalloc mode, nr_allocated should stay zero until
- -		 * the entire allocation is filled
- -		 */
- -		if (unlikely(bigalloc && nr_allocated)) {
- -			reiserfs_warning(s, "bigalloc is %d, nr_allocated %d\n",
- -					 bigalloc, nr_allocated);
- -			/* reset things to a sane value */
- -			bigalloc = amount_needed - nr_allocated;
- -		}
- -		/*
- -		 * try pass 0 and pass 1 looking for a nice big
- -		 * contiguous allocation.  Then reset and look
- -		 * for anything you can find.
- -		 */
- -		if (passno == 2 && bigalloc) {
- -			passno = 0;
- -			bigalloc = 0;
- -		}
 		switch (passno++) {
 		case 0:	/* Search from hint->search_start to end of disk */
 			start = hint->search_start;
@@ -1106,8 +1086,7 @@
 								 new_blocknrs +
 								 nr_allocated,
 								 start, finish,
- -								 bigalloc ?
- -								 bigalloc : 1,
+								 1,
 								 amount_needed -
 								 nr_allocated,
 								 hint->


- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFExATJLPWxlyuTD7IRAmeKAJsFI/awPPAXpB2DI+kO19EZtr3tRwCfWduO
Re+5kXNtj6St/LuUy9lbNm4=
=anQd
-----END PGP SIGNATURE-----



From: Hans Reiser [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 16:35:07 -0600

Jeff Mahoney wrote:

>
>
> Anyone up for it? :) There are changes I'd like to see in reiser3,
> particularly ones that address the severe problems observed in David
> Chinner's high bandwidth file system talk this year at OLS. Specifically,
> it ended up making very little progress and spending the majority of the
> time in the journal when the workload is streaming data at the disk at a
> very high rate on a very large file system. Yes, that is certainly XFS's
> sweet spot, but barely making progress at all is a bit more severe than
> "poor performance." Perhaps mkreiserfs should be a bit saner about
> choosing
> journal sizes, since a 32 MB journal is not a good fit for all cases.
> Also,
> I'd like to see the usage of the BKL gone as it severely limits
> performance
> when more than one thread is writing to the file system, or even another
> reiserfs file system. It's not entirely low hanging fruit since the nested
> cases need to be audited, but it shouldn't be too hard to eliminate the
> inter-filesystem lock contention by replacing the BKL with a per-sb mutex.

Getting rid of the BKL is a huge task that was done in V4 for a reason. 
You are talking about 6+ man-months, and years of shake-out to fully
debug.  Actually, it is a tribute to Zam's skill that V4's locking got
debugged so fast: I gave him the task knowing it was going to be the
hardest code to debug, and he did it very well.

These things you discuss, except for the journal size, are not things to
fix in a stable branch.

My apologies that I thought this was a new bug.  Let us be glad that a
user gave us enough detail we saw it.

> I have some more things, but I have nowhere near the time to do them,
> and other file systems will perform fine.


From: Steve Lord [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Sun, 23 Jul 2006 21:08:18 -0500

Theodore Tso wrote:
> On Fri, Jul 21, 2006 at 01:46:18PM -0600, Hans Reiser wrote:

>> Consider what happened with XFS as the article writer mentions.  I met
>> the original XFS team, led by two very senior developers (Jim Grey, and
>> another fellow whose name I am blanking on, forgive me, I learned much
>> from him in just a few conversations).  

Not sure who Jim Grey was, he never worked on XFS, ah well.

> 
> I believe you are referring to Jim Mostek and Steve Lord, and yes,
> they were very talented developers and engineers.  I very much enjoyed
> talking to them at various filesystem and Linux conferences and
> workshops.
> 
>> supervision.  What happened?  They got hassled.  Instead of learning
>> from them, welcoming into our community two very senior developers who
>> knew a lot more than any of us about the topics they chose to speak
>> about, they got hassled, they get ignored, they felt rejected, and left
>> the Linux community forever, never to return.  
> 
> That's hardly what happened.  SGI went through layoffs, and they were
> hit.  See:  http://slashdot.org/articles/01/05/26/0743254.shtml
> 

Ted, you of all people should know not believe all you read on
slashdot ;-) 'Linuxcare helping out with the funding' ha!

Both Jim Mostek and I left under our own steam at different times, Jim
in 2000 and myself in 2003. SGI still has great technology to work on
and, but the you can only take so many years of bad financial results
and watching people get layed off.

I still work on Linux, and follow development as much as I can. I keep
trying  to get back to OLS, but circumstances keep conspiring against
me, maybe next year.

Steve Lord



From: Nikita Danilov [email blocked]
Newsgroups: gmane.linux.kernel
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Mon, 24 Jul 2006 11:53:08 +0400

Steve Lord writes:
 > Theodore Tso wrote:
 > > On Fri, Jul 21, 2006 at 01:46:18PM -0600, Hans Reiser wrote:
 > 
 > >> Consider what happened with XFS as the article writer mentions.  I met
 > >> the original XFS team, led by two very senior developers (Jim Grey, and
 > >> another fellow whose name I am blanking on, forgive me, I learned much
 > >> from him in just a few conversations).  
 > 
 > Not sure who Jim Grey was, he never worked on XFS, ah well.

I believe the (mis-)reference is to a famous data-base person, co-author
of "Transaction Processing". He is with Microsoft now
(http://research.microsoft.com/~Gray/JimGrayHomePageSummary.htm).

 > 
 > Steve Lord

Nikita.



From: Theodore Tso [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Mon, 24 Jul 2006 06:30:23 -0400

On Mon, Jul 24, 2006 at 11:53:08AM +0400, Nikita Danilov wrote:
> 
> I believe the (mis-)reference is to a famous data-base person, co-author
> of "Transaction Processing". He is with Microsoft now
> (http://research.microsoft.com/~Gray/JimGrayHomePageSummary.htm).
> 

That's what I thought when I saw the name Jim Gray, but as far as I
knew he never worked on XFS and never left the Linux community
dejected because Linux kernel coding standards requirements before
changes were allowed to be merged, when Hans did his name dropping
thing.

(I mean geez, if you want really high standards before new code is
accepted, take a look at Open Solaris; they have *such* a heavyweight
process, with two mandatory signoffs by core Solaris engineers who
both have to do a line-by-line review, and with a promise of on-disk
and ABI compatibility *forever* ---- that we do more commits in a week
than they do in a year....)

						- Ted



From: Olivier Galibert [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Mon, 24 Jul 2006 13:35:34 +0200

On Mon, Jul 24, 2006 at 06:30:23AM -0400, Theodore Tso wrote:
> (I mean geez, if you want really high standards before new code is
> accepted, take a look at Open Solaris; they have *such* a heavyweight
> process, with two mandatory signoffs by core Solaris engineers who
> both have to do a line-by-line review, and with a promise of on-disk
> and ABI compatibility *forever* ---- that we do more commits in a week
> than they do in a year....)

That sounds almost like gcc, only worse.

I think there is something of a problem currently, tough.  It is
getting too hard to get code in if you're not a maintainer for an
existing subsystem (reiser4, suspend2...), and too easy when you're a
maintainer (ext4, uswsusp...).  Ext patches don't get reviewed much
outside of the developpers, and they go in pretty much without
discussion in any case, except when Linus blows a fuse.  Reiser4 would
have be in without discussion if it had been a set of patches through
time to reiser3, and would have been called 4 only when Linus yelled.
I suspect some balancing would be useful.

  OG.



From: Theodore Tso [email blocked]
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Date:	Mon, 24 Jul 2006 09:39:39 -0400

On Mon, Jul 24, 2006 at 01:35:34PM +0200, Olivier Galibert wrote:
>Ext patches don't get reviewed much
> outside of the developpers, and they go in pretty much without
> discussion in any case, except when Linus blows a fuse.

Um, you're kidding, right?  We certainly don't make the assumption
that we can violate CodingStyle willy nilly and stuff in yacc grammers
into ext3 and assume that no one will push back.

In fact we did a lot of work to make sure the patches were clean and
mostly ready to be accepted to mainline even before we made the first
proposal to push extents to LKML.

> I think there is something of a problem currently, tough.  It is
> getting too hard to get code in if you're not a maintainer for an
> existing subsystem (reiser4, suspend2...), and too easy when you're a
> maintainer (ext4, uswsusp...).  

It's not fair to assume that the only reason why non-maintainers have
a harder time getting changes is because their changes are getting
more intensive review.  (Although it is the case that we probably do
need to get better at reviewing changes that go in via git trees.)  A
much more important effect is that non-maintainers aren't familiar
with coding and patch submission guidelines.  For example, in
suspend2, Nigel first tried with patches that were too monolithic, and
then his next series was too broken down such that it was too hard to
review (and "git bisect" wouldn't work).  And of course, there are
people who assume that the rules shouldn't apply to their filesystem...

						- Ted
						

• Archive of above thread