Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

 

 

First page Previous page 1 2 3 4 5 6 7 8 9 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


reiser at namesys

Jul 21, 2006, 12:46 PM

Post #1 of 223 (25966 views)
Permalink
the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 21, 2006, 5:18 PM

Post #2 of 223 (25562 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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

> 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.

After two users asked the "Why is Reiser4 still not included?" question
within a very short amount of time on this list (mailing lists aren't
write-only, and this issue has been discussed often before...), Diego
wrote an FAQ for this issue.

Emails by people like Linus, Andrew, Christoph or Al are what comes
nearest to an official statement.

If there are factual errors or things you consider offensive in the FAQ,
please try to discuss them with Diego privately first. But changing
contents of this FAQ wouldn't change anything regarding the Reiser4
inclusion - the FAQ is only a high level description of the Reiser4
situation for end users.

> 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?

The main difference seems to be that ext4 is being developed by people
that have already shown and are trusted to develop a filesystem that
follows the Linux way in all respects.

Note that I didn't say "right way" but "Linux way".

No matter whether it's coding style or the discussion which
functionality belongs to the VFS level, the Linux kernel has it's (often
unwritten) rules - but the same is true with other rules for any other
operating system.

>...
> 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.

A very important part of a review is whether it follows the
"Linux way" that might be quite different from what someone who comes
from outwards has to learn before he can start doing a review.

Finding people for the cool stuff like developing a new filesystem is
relatively easy compared to finding people why are both capable and
willing to do the boring work of reviewing other people's code.

So we'd need people who are already acknowleged experts in the area, who
are willing to learn the Linux way, and who will then do the not-fun
work of reviewing other people's code.

How should this work?
Someone has to offer well-paid jobs for such people?

> 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.

In my experience, the Linux kernel is a big open source project with a
working structure.

The Linux kernel sometimes looses developers.

That seems to unavoidable, there are there are always problems like:
- Some developers leave the projects if their code was rejected because
it didn't match the standards and policies of the project.
- Some developers leave the project if other people's code that didn't
match the standards and policies of the project was accepted.

And it's not as if open source projects had in any respect better
prerequisites than large corporations - open source lacks the "it's our
job" glue forcing people to work together in large corporations.

>...
> Hans

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


tytso at mit

Jul 22, 2006, 6:02 AM

Post #3 of 223 (25559 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


sandeen at sandeen

Jul 22, 2006, 7:30 AM

Post #4 of 223 (25561 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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).
>
> 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

Jim & Steve were never laid off from SGI. SGI mgmt -was- smarter than that ;)
Neither account above is 100% correct, but I won't speak further on behalf of
these gentlemen...

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


LuukvanderDuim at pahw

Jul 22, 2006, 8:21 AM

Post #5 of 223 (25557 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Adrian wrote:
--
The Linux kernel sometimes looses developers.

That seems to unavoidable, there are there are always problems like:
- Some developers leave the projects if their code was rejected because
it didn't match the standards and policies of the project.
- Some developers leave the project if other people's code that didn't
match the standards and policies of the project was accepted.

--


*Cough*DonaldBecker AndreHedrick*Cough*
..


Luuk

-------------------------------------------------------------------------------------------------------------

Disclaimer:
By sending an email to ANY of my addresses you are agreeing that:

1. I am by definition, "the intended recipient"
2. All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it on usenet.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that may be included on your message.





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 22, 2006, 11:33 AM

Post #6 of 223 (25570 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


diegocg at gmail

Jul 22, 2006, 12:19 PM

Post #7 of 223 (25548 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

El Sat, 22 Jul 2006 02:18:19 +0200,
Adrian Bunk <bunk [at] stusta> escribió:

> After two users asked the "Why is Reiser4 still not included?" question
> within a very short amount of time on this list (mailing lists aren't
> write-only, and this issue has been discussed often before...), Diego
> wrote an FAQ for this issue.
>
> Emails by people like Linus, Andrew, Christoph or Al are what comes
> nearest to an official statement.

[I'm the guy who wrote the doc]

I didn't write "It could possibly be ready as soon as 2.6.19" literally,
that was someone that reworked my (ugly) english. Being fair what make
me wrote that pages was the huge amount of people FUDing about linux
developers in online forums (including this list)

> > 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

Hans, stop that "we're smarter than you" attitude. It's not surprising
that reiser 4 creates so many flames and that it's getting so hard to make
progress, with such strong arguments. As far as I can tell, most of the
kernel hackers trust Al Viro and hch on their opinions, specially in
fs-related issues - and for good reasons. They know linux and they
know how a linux fs must behave. As long as a fs plays well with the
rest of the system and the code doesn't suck, I doubt they care too
much if it's very advanced or arcane, and the huge variety of
filesystem available in linux confirms that.

> > 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.

Hans, I don't agree. If anything, the problem is that right now there's
not a "development" stage: people just takes more care about what goes
in, it wouldn't happen the same under a development stage. That certainly
could make the job of big projects like reiser 4 much harder.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeff at garzik

Jul 22, 2006, 1:29 PM

Post #8 of 223 (25569 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rene at exactcode

Jul 23, 2006, 12:20 AM

Post #9 of 223 (25539 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Hi,

On Saturday 22 July 2006 15:02, Theodore Tso wrote:
> > 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)

However I would estimate that Reiser4 is used by more people than yet
aother ext2 patchups.

Yours,

--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 23, 2006, 12:20 AM

Post #10 of 223 (25564 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


lkml at lpbproductions

Jul 23, 2006, 2:12 AM

Post #11 of 223 (25548 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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.







-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jbglaw at lug-owl

Jul 23, 2006, 4:48 AM

Post #12 of 223 (25557 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Sun, 2006-07-23 01:20:40 -0600, Hans Reiser <reiser [at] namesys> wrote:
> There is nothing about small patches that makes them better code. There

Erm, a small patch is something which should _obviously_ fix one
issue. A small patch, containing at max some 100 lines, can easily be
read and understood.

A complete filesystem (I'm co-maintaining one for an ancient on-disk
format, too) isn't really easy to understand or to verify from looking
at it for 5min.

> 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.

I give a shit of nothing to some 5 year work if I cannot verify that
it won't hurt me at some point.

> 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.

Just put reiser4 in some GIT tree and publish it. Maybe you can place
it on git.kernel.org .

MfG, JBG

--
Jan-Benedict Glaw jbglaw [at] lug-owl +49-172-7608481
Signature of: ...und wenn Du denkst, es geht nicht mehr,
the second : kommt irgendwo ein Lichtlein her.
Attachments: signature.asc (0.18 KB)


andre.goddard at gmail

Jul 23, 2006, 11:26 AM

Post #13 of 223 (25528 views)
Permalink
RE: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Jeff Garzik wrote:
> 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:

Hi, Hans!

I think you are mostly right in your conclusions, it is sad but
true that we lose very good developers sometimes. I hope this
can be changed by emails like yours in the long run.

I would like to see you and Christoph working again with synergy
(with harmony), but you have insulted him in the past. I regret this
happened and I think reiser4 would be already with us all if you had
focused at the technical discussion with him. I know that sometimes
it is difficult but we must all learn with Greg Kroah-Hartman, one of
the major contributors in volume to the kernel: be highly diplomatic
and respectfull. See more here:

http://os.newsforge.com/os/06/07/23/1212252.shtml?tid=2&tid=138

The arguments Jeff presented are super strong and are backed by an
entire past thread where Linus and others share a sharp clear vision
which I think that works very well in practice:

http://www.kernel-traffic.org/kernel-traffic/kt19991101_41.html#6

They are _right_ (tm) here. We all know they are from our experiences
in past mistakes.

I would like to thank you for reiser4, it is great! Please use your
diplomacy to get more reviews. After getting the code reviewed, fix the
complaints or discuss technically your POV.
We all want reiser4 in (I do think it is great), but after reviewed by the
filesystem experts.

Thank you and the reiser4 team!

--
[]s,
André Goddard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeffm at suse

Jul 23, 2006, 1:46 PM

Post #14 of 223 (25537 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 23, 2006, 2:15 PM

Post #15 of 223 (25547 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 23, 2006, 3:35 PM

Post #16 of 223 (25540 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jeffm at suse

Jul 23, 2006, 4:22 PM

Post #17 of 223 (25543 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


lord at xfs

Jul 23, 2006, 7:08 PM

Post #18 of 223 (25564 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 23, 2006, 9:01 PM

Post #19 of 223 (25550 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nikita at clusterfs

Jul 24, 2006, 12:49 AM

Post #20 of 223 (25547 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Rene Rebe writes:
> Hi,
>
> On Saturday 22 July 2006 15:02, Theodore Tso wrote:
> > > 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)
>
> However I would estimate that Reiser4 is used by more people than yet
> aother ext2 patchups.

Any data backing up that estimation? Just to give an example, that
"patchup" is used by (tens of) thousands of computers in governmental
laboratories the US "national security" depends upon.

>
> Yours,

Nikita.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nikita at clusterfs

Jul 24, 2006, 12:53 AM

Post #21 of 223 (25539 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 24, 2006, 1:09 AM

Post #22 of 223 (25516 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Matthias Andree wrote:

>The most worrying point was that reiser3 maintenance was given up at the
>point where it was just about to transition from usable to mature.
>
>
>
Name a bug (not a feature) that has not been fixed by us, and which is
not also so deep that it reasonably required waiting for a major release
to fix it (for example, bug fixes that require disk format changes
belong in v4 not v3 even if a case can be made that they are bug fixes).

I mean, god, sometimes I think users are like little children waiting
for the pie that is in the oven and who want to take it out now before
it finishes cooking so they can eat it, and they are very angry about
it, and I should just understand that and not try to reason with it (but
also not give them the pie before it finishes cooking either). Someone
please tell me I don't understand the users and it all makes more sense
than that, please....

No code before its time. No features in stable branches. Wait for it.
Stop complaining about how you are abandoned, we are working hard. It's
going to be the best pie ever. Wait for it.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 24, 2006, 1:13 AM

Post #23 of 223 (25550 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Matthias Andree wrote:

> The father declared his child unsupported,
>
I never did that.

>and that's the end
>of the story for me. There's nothing wrong about focusing on newer code,
>but the old code needs to be cared for, too, to fix remaining issues
>such as the "can only have N files with the same hash value".
>
Requires a disk format change, in a filesystem without plugins, to fix it.

>(I am well
>aware this is exploiting worst-case behavior in a malicious sense but I
>simply cannot risk such nonsense on a 270 GB RAID5 if users have shared
>work directories.)
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


matthias.andree at gmx

Jul 24, 2006, 1:41 AM

Post #24 of 223 (25571 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Sat, 22 Jul 2006, Jeff Garzik wrote:

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

That reminds me of the old "layer 8 and 9" extensions to the OSI/ISO
layering model. Layer 8: financial, Layer 9: policital.

SCNR.

> 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.

The most worrying point was that reiser3 maintenance was given up at the
point where it was just about to transition from usable to mature.

--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


matthias.andree at gmx

Jul 24, 2006, 1:54 AM

Post #25 of 223 (25550 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Sun, 23 Jul 2006, Hans Reiser wrote:

> 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.

Well, I, with the administrator hat on, phased out all reiserfs file
systems and replaced them by ext3. This got me rid of silent
corruptions, immature reiserfsprogs and hash collision chain limits.

> 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.

And that is something that an administrator does not care the least
about. It must simply work, and the tools must simply work. Once I hit
issues like "xfs_check believes / were mounted R/W (not ignoring rootfs)
and refuses the R/O check", "reiserfsck can't fix a R/O file system"
(I believed this one got fixed before 3.6.19) or particularly silent
corruptions that show up later in a routine fsck --check after a kernel
update, the filesystem and its tools appear in a bad light. I've never
had such troubles with ext2fs or ext3fs or FreeBSD's or Solaris's ufs.

I'm not sure what patches Chris added to SUSE's reiserfs, nor do I care
any more. The father declared his child unsupported, and that's the end
of the story for me. There's nothing wrong about focusing on newer code,
but the old code needs to be cared for, too, to fix remaining issues
such as the "can only have N files with the same hash value". (I am well
aware this is exploiting worst-case behavior in a malicious sense but I
simply cannot risk such nonsense on a 270 GB RAID5 if users have shared
work directories.)

--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 3 4 5 6 7 8 9 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.