the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Hans Reiser
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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Neil Brown
Hi Hans,
On Friday July 21, rei...@namesys.com wrote:
>
> 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.
You seem to be saying that technological skills are the most important
thing for Linux. I disagree. Linux is a success because of a great
community as much (probably more) than because it has great
technology.
And by "great community", I don't mean "completely harmonious" but
rather "board and effective". Good community members follow the rule
"Be liberal in what you accept, conservative in what you transmit".
And the first if these is the more important.
Not everyone in the community is perfect at this, but it is clear to
me that those who excel at this are what makes the community work.
> 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.
This just tells me that they wouldn't make good community members -
they are not sufficiently liberal in what they accept.
It really isn't that hard to filter out the rubbish and look for the
genuine technical content. For some people there isn't any of the
later so you just ignore them. For others there is real technical
content in what they say and you can respond to that while ignoring
the rubbish.
> lkml suffers from
> email disease, and we need to make conscious efforts to reduce that.
Yes. But as this is a free and open community, we cannot exclude or
censor people. The only emails that we can directly control are our
own. We should expect the general standard of the community to be
below the standard we present, and aim accordingly. I see this
happening. It works. The community isn't perfect, but it could be a
lot worse.
> 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.
Yes, and no.
Certainly a few more akpms would improve the technology, and would
allow our current akpm to catch up with his workload.
But I don't think a few more of anything would dramatically change the
community. There will always be people who attract flames, and others
who are too willing to provide them.
New members to the community really need to sit back for a while and
figure out who is who. Who is worth listening to. Who is best
ignored (except for entertainment value). Who to ask questions of,
etc.
It really is worth the effort.
There is plenty of historical evidence that the best technology
doesn't always win out - there are plenty of other factors to
success. So don't be too concerned if we lose a few brilliant
technologists - it isn't the end of the world (domination).
NeilBrown
Adrian Bunk
> 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
Theodore Tso
> 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
Eric Sandeen
> 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
Diego Calleja
Adrian Bunk <bu...@stusta.de> 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.
Hans Reiser
>
>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
Jeff Garzik
> 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
Rene Rebe
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
Hans Reiser
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
Matt Heler
> 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.
Jan-Benedict Glaw
> 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 jbg...@lug-owl.de +49-172-7608481
Signature of: ...und wenn Du denkst, es geht nicht mehr,
the second : kommt irgendwo ein Lichtlein her.
André Goddard Rosa
> 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
Jeff Mahoney
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-----
Hans Reiser
>
>
> 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
Jeff Mahoney
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-----
Hans Reiser
>
>
> 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.
>
>
>
-
Steve Lord
> 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
Hans Reiser
>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
Nikita Danilov
> 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.
Nikita Danilov
> 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.
Matthias Andree
> 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
Matthias Andree
> 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
Hans Reiser
> 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.)
>
>
>
>
-
Hans Reiser
>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
Matthias Andree
> >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.
You see, I don't care a iota about "plugins" or other implementation details.
The bottom line is reiserfs 3.6 imposes practial limits that ext3fs
doesn't impose and that's reason enough for an administrator not to
install reiserfs 3.6. Sorry.
--
Matthias Andree
Theodore Tso
>
> 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
Matthias Andree
> 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....
namesys.com doesn't list reiserfs 3.6 hash collision limits in an easy
to find place (which would be the same place that boasts about 100,000
files per directory if it wants to be honest).
> 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.
I'm not going to eat it while it's still steaming and fogging my glasses.
You're now making the same noise about how good reiser4 is that was made
when reiserfs 3.5 was a patch for Linux 2.2 and that wedged local access
when NFS exported, and 3.6 didn't fix the hash collision issue (but
required a format change, too, right).
--
Matthias Andree
Olivier Galibert
> (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.
Christian Iversen
> On Mon, 24 Jul 2006, Hans Reiser wrote:
> > >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.
>
> You see, I don't care a iota about "plugins" or other implementation
> details.
>
> The bottom line is reiserfs 3.6 imposes practial limits that ext3fs
> doesn't impose and that's reason enough for an administrator not to
> install reiserfs 3.6. Sorry.
And what do you do if you, say, run of of inodes on ext3? Do you think the
users will care about that? Or what if the number of files in your mail queue
or proxy cache* become large enough for your fs operations to slow to a
crawl?
* Yes I know most programs work around this by using many subdirs, but that's
really a bandaid solution.
--
Regards,
Christian Iversen
Erik Mouw
> On Monday 24 July 2006 12:25, Matthias Andree wrote:
> > The bottom line is reiserfs 3.6 imposes practial limits that ext3fs
> > doesn't impose and that's reason enough for an administrator not to
> > install reiserfs 3.6. Sorry.
>
> And what do you do if you, say, run of of inodes on ext3? Do you think the
> users will care about that?
From what I've seen from our customers, that never happens. Yes, there
are sometimes people with a million inodes in use, and we've seen four
million once, but that's never been a problem, even not with a huge
mail server with thousands of users having mailboxes in maildir format.
We usually limit our own filesystems to 12 million inodes and it's
never been a problem to store files from our customers.
> Or what if the number of files in your mail queue
> or proxy cache* become large enough for your fs operations to slow to a
> crawl?
Not a problem anymore with htree dirextory indexing. If it's not yet
enabled (dumpe2fs the filesystem and look for the "dir_index" feature),
enable it with:
tune2fs -O dir_index /dev/whatever
After the next mount the filesystem will use it for new directories. To
optimize existing directories, run e2fsck -D.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
Theodore Tso
>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
Horst H. von Brand
> 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.
Got that one wrong.
Layer 8: User
Layer 9: Political
Layer 10: Financial
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Olivier Galibert
> 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.
I'm not kidding. I do recognise that the ext* maintainers do a very
good and clean job.
> 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'm no talking about extends only. Ext3 now is very, very different
than the ext2+journal it was at the start, with backwards-incompatible
format changes added all the time[1]. These changes went in
no-questions-asked.
> > 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.
"only", no, definitively not. The impact is non-negligible though.
> (Although it is the case that we probably do
> need to get better at reviewing changes that go in via git trees.)
Ohh yes, a lot better. Just look at ALSA, most of SNDRV_HWDEP* should
never have gotten in in the first place, especially some recent ones
like SNDRV_HWDEP_IFACE_SB_RC, and even some (SNDRV_HWDEP_IFACE_USX2Y*)
are security holes the size of Cleveland. I need to continue
documenting the Alsa kernel interface, but I need a new bucket, the
first one is overflowing.
> 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).
All his submissions since 2004 or so? It's a little easy to limit
oneself to the last two ones.
> And of course, there are people who assume that the rules shouldn't
> apply to their filesystem...
It may be a little hard to remove XFS at that point though... And,
while it's not a filesystem, I'd love to be pointed to the technical
discussion deciding whether uswsusp is a good idea.
OG.
[1] All optional, I know.
Theodore Tso
> I'm no talking about extends only. Ext3 now is very, very different
> than the ext2+journal it was at the start, with backwards-incompatible
> format changes added all the time[1]. These changes went in
> no-questions-asked.
The patches indeed were reviewed and changes made in response to the
reviews. The philosophical/design question about whether or not
optional features which, if enabled, would prevent older kernels to
mount the filesystem was not asked, no. But that doesn't mean that
the code was not reviewed; it was.
I would also note that we didn't intimate that we knew better than the
reviewers, or question their motives, or otherwise insult the
reviewers such that they might decide they have better things to do
than to review our patches, and that might have had something to do
with how the code got in relatively painlessly....
- Ted
Mike Benoit
> On Mon, 24 Jul 2006, Hans Reiser wrote:
>
> > >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.
>
> You see, I don't care a iota about "plugins" or other implementation details.
>
> The bottom line is reiserfs 3.6 imposes practial limits that ext3fs
> doesn't impose and that's reason enough for an administrator not to
> install reiserfs 3.6. Sorry.
>
And EXT3 imposes practical limits that ReiserFS doesn't as well. The big
one being a fixed number of inodes that can't be adjusted on the fly,
which was reason enough for me to not use EXT3 and use ReiserFS
instead.
Do you consider the EXT3 developers to have "abandoned" it because they
haven't fixed this issue? I don't, I just think of it as using the right
tool for the job.
I've been bitten by running out of inodes on several occasions, and by
switching to ReiserFS it saved one company I worked for over $250,000
because they didn't need to buy a totally new piece of software.
I haven't been able to use EXT3 on a backup server for the last ~5 years
due to inode limitations. Instead, ReiserFS has been filling that spot
like a champ.
The bottom line is that every file system imposes some sort of limits
that bite someone. In your case it sounds like EXT3 limits weren't an
issue for you, in my case they were. Thats life.
--
Mike Benoit <ip...@snappymail.ca>
Matthias Andree
> I've been bitten by running out of inodes on several occasions, and by
> switching to ReiserFS it saved one company I worked for over $250,000
> because they didn't need to buy a totally new piece of software.
ext3fs's inode density is configurable, reiserfs's hash overflow chain
length is not, and it doesn't show in df -i either.
If you need lots of inodes, mkfs for lots. That's old Unix lore.
Olivier Galibert
> I would also note that we didn't intimate that we knew better than the
> reviewers, or question their motives, or otherwise insult the
> reviewers such that they might decide they have better things to do
> than to review our patches, and that might have had something to do
> with how the code got in relatively painlessly....
Now that has a very high impact :-) Hans is not very good at the
diplomacy game.
The fact that the ext maintainers are very, very good helps quite a
lot too. But I think it doesn't change the fact that if r4 has been a
set of patches through time to r3, good or not, there wouldn't be a
discussion.
It's maybe the lack of an official development branch, but it looks
like the kernel development has become very risk-averse, and the bar
is set much higher to accept anything that looks relatively new. Any
reason is good to have it dropped, cosmetic or not.
Just to give you an idea, if the criteria applied to suspend2 or
reiser4 had been applied to everything else, we wouldn't have at least
XFS[1], ALSA[2], sysfs[3] and DRM[4]. Whether it is good or bad is an
interesting question itself. But before, code just had to be
reasonably sane, and it was expected to be fixed through time. Some
even has been (sysfs got better). Now it has to attain an ever moving
level of perfection before it has a chanc to be accepted.
Unless you're a maintainer, that is, for which you can get pretty much
anything in that doesn't immediatly break the compile through git
trees. Thankfully, most of the maintainers are sane.
Don't you think this is a problem?
OG.
[1] CodingStyle is for the weak
[2] You call that a kernel interface? HWDEP? ioctl to read/write
samples instead of read/write?
[3] Lifetime rules and locking are for other people to care about
[4] Oh my, people are still trying to fix that one
Horst H. von Brand
> On Mon, 2006-07-24 at 12:25 +0200, Matthias Andree wrote:
> > On Mon, 24 Jul 2006, Hans Reiser wrote:
> >
> > > >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.
> > You see, I don't care a iota about "plugins" or other implementation details.
> >
> > The bottom line is reiserfs 3.6 imposes practial limits that ext3fs
> > doesn't impose and that's reason enough for an administrator not to
> > install reiserfs 3.6. Sorry.
> And EXT3 imposes practical limits that ReiserFS doesn't as well. The big
> one being a fixed number of inodes that can't be adjusted on the fly,
Right. Plan ahead.
> which was reason enough for me to not use EXT3 and use ReiserFS
> instead.
I don't see this following in any way.
> Do you consider the EXT3 developers to have "abandoned" it because they
> haven't fixed this issue? I don't, I just think of it as using the right
> tool for the job.
Dangerous parallel, that one...
> I've been bitten by running out of inodes on several occasions,
Me too. It was rather painful each time, but fixable (and in hindsight,
dumb user (setup) error).
> and by
> switching to ReiserFS it saved one company I worked for over $250,000
> because they didn't need to buy a totally new piece of software.
How can a filesystem (which by basic requirements and design is almost
transparent to applications) make such a difference?!
> I haven't been able to use EXT3 on a backup server for the last ~5 years
> due to inode limitations.
See comment above. Read mke2fs(8) with care.
> Instead, ReiserFS has been filling that spot
> like a champ.
Nice for you.
> The bottom line is that every file system imposes some sort of limits
> that bite someone.
Mostly that infinite disks are hard to come by ;-)
> In your case it sounds like EXT3 limits weren't an
> issue for you, in my case they were.
I'd suspect the limits you ran into weren't exactly in ext3.
> Thats life.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Jeff Garzik
> The fact that the ext maintainers are very, very good helps quite a
> lot too. But I think it doesn't change the fact that if r4 has been a
> set of patches through time to r3, good or not, there wouldn't be a
> discussion.
That's a huuuuuge leap of logic.
Metadata plugins found in reiser4 are far better done at the VFS level,
than burying "reiser4 can look like ext2, if it wishes" functionality
inside the filesystem.
I guarantee such a patch to reiser3 would get rejected.
> It's maybe the lack of an official development branch, but it looks
> like the kernel development has become very risk-averse, and the bar
> is set much higher to accept anything that looks relatively new. Any
> reason is good to have it dropped, cosmetic or not.
New stuff goes in all the time.
The bar is set too high in some cases (read: SCSI subsystem
submissions), but reiser4 submission cannot be generalized as you have
done here. There are very real issues present, that need to be dealt with.
> Just to give you an idea, if the criteria applied to suspend2 or
> reiser4 had been applied to everything else, we wouldn't have at least
> XFS[1], ALSA[2], sysfs[3] and DRM[4]. Whether it is good or bad is an
> interesting question itself. But before, code just had to be
> reasonably sane, and it was expected to be fixed through time. Some
> even has been (sysfs got better). Now it has to attain an ever moving
> level of perfection before it has a chanc to be accepted.
reiser4 tries to be another VFS. That's a bit more than needing
additional minor fixes over time.
Jeff
Valdis.K...@vt.edu
> Mike Benoit wrote:
>
> > I've been bitten by running out of inodes on several occasions, and by
> > switching to ReiserFS it saved one company I worked for over $250,000
> > because they didn't need to buy a totally new piece of software.
>
> ext3fs's inode density is configurable, reiserfs's hash overflow chain
> length is not, and it doesn't show in df -i either.
Equally important - you can usually *see* "out of inodes" coming on a 'df -i'
long before a reiser3 filesystem hits the wall on a hash issue.
Mike Benoit
> > And EXT3 imposes practical limits that ReiserFS doesn't as well. The big
> > one being a fixed number of inodes that can't be adjusted on the fly,
>
> Right. Plan ahead.
That is great in theory. But back to reality, when your working for a
company that is growing by leaps and bounds that isn't always possible.
Why would I want to intentionally limit myself to a set number of inodes
when I can get a performance increase and not have to worry about it by
simply using ReiserFS?
It all boils down to using the right tool for the job, ReiserFS was the
right tool for this job.
> > I've been bitten by running out of inodes on several occasions,
>
> Me too. It was rather painful each time, but fixable (and in hindsight,
> dumb user (setup) error).
>
> > and by
> > switching to ReiserFS it saved one company I worked for over $250,000
> > because they didn't need to buy a totally new piece of software.
>
> How can a filesystem (which by basic requirements and design is almost
> transparent to applications) make such a difference?!
Very easily, the backup software the company had spent ~$75,000 on
before I started working there used tiny little files as its "database".
Once the inodes ran out the entire system pretty much came to a
screeching halt. We basically had two options, use ReiserFS, or find
another piece of software that didn't use tiny little files as its
database. If I recall correctly the database went from about 2million
files to over 40 million in the span of just a few months. No one could
have predicted that. I believe this database was on an 18GB SCSI drive,
so even using 1K blocks wouldn't have worked. According to the mke2fs
man page:
"-i bytes-per-inode
This value generally shouldn't be smaller than the blocksize of
the filesystem, since then too many inodes will be made."
The only other option at that time was to purchase Veritas backup and
its not cheap. We ended up switching to ReiserFS, it increased our
backup/restore time immensely and also bought us about 1year before the
system finally outgrew itself for good. By that time the company could
afford to drop $250,000 on high end backup software so we could grow
past 10TB.
--
Mike Benoit <ip...@snappymail.ca>
Jan-Benedict Glaw
Erm, how does your data look like and why does it require a $250,000
backup solution? Sounds like I'm in the wrong business...
But that's for sure not lkml related...
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
Signature of: Don't believe in miracles: Rely on them!
the second :
Horst H. von Brand
> On Mon, 2006-07-24 at 14:06 -0400, Horst H. von Brand wrote:
> > > one being a fixed number of inodes that can't be adjusted on the fly,
> > Right. Plan ahead.
> That is great in theory. But back to reality, when your working for a
> company that is growing by leaps and bounds that isn't always possible.
> Why would I want to intentionally limit myself to a set number of inodes
> when I can get a performance increase and not have to worry about it by
> simply using ReiserFS?
Place your filesystems on LVN, when they grow the number of inodes grows to
match. Or did you run out of inodes and not of diskspace? Only ever
happened to me on (static) /dev, or (wrong configured) newsspools...
> It all boils down to using the right tool for the job, ReiserFS was the
> right tool for this job.
/One/ tool that did the job. Not "the" right one, perhaps not even the best
one.
> > > I've been bitten by running out of inodes on several occasions,
> > Me too. It was rather painful each time, but fixable (and in hindsight,
> > dumb user (setup) error).
> > > and by
> > > switching to ReiserFS it saved one company I worked for over $250,000
> > > because they didn't need to buy a totally new piece of software.
> > How can a filesystem (which by basic requirements and design is almost
> > transparent to applications) make such a difference?!
> Very easily, the backup software the company had spent ~$75,000 on
> before I started working there used tiny little files as its "database".
If you know that, you configure your filesystem like a newsspool or some
such.
> Once the inodes ran out the entire system pretty much came to a
> screeching halt.
Get a clue by for, apply to the vendor (for the design, or at the very
least for not warning unsuspecting users)?
> We basically had two options, use ReiserFS, or find
> another piece of software that didn't use tiny little files as its
> database.
Or reconfigure the filesystem with more inodes (you were willing to rebuild
the filesystem in any case, so...)
> If I recall correctly the database went from about 2million
> files to over 40 million in the span of just a few months. No one could
> have predicted that. I believe this database was on an 18GB SCSI drive,
> so even using 1K blocks wouldn't have worked. According to the mke2fs
> man page:
> "-i bytes-per-inode
> This value generally shouldn't be smaller than the blocksize of
> the filesystem, since then too many inodes will be made."
18GiB = 18 million KiB, you do have a point there. But 40 million files on
that, with some space to spare, just doesn't add up.
> The only other option at that time was to purchase Veritas backup
... or a larger disk...
> and
> its not cheap. We ended up switching to ReiserFS, it increased our
> backup/restore time immensely and also bought us about 1year before the
> system finally outgrew itself for good. By that time the company could
> afford to drop $250,000 on high end backup software so we could grow
> past 10TB.
Paul Jackson
> Jim Grey
Sounds like the name of Jim Gray, the famous database and transaction
processing expert of IBM, Tandem, DEC and Microsoft.
Neither SGI nor XFS has had the honor of working with Jim Gray.
The original XFS developers and designers include Geoff Peck, Jeff
Glover, Adam Sweeney and Doug Doucette, from what I can see from my
notes dating back to 1993/1994 on this.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.925.600.0401
Hans Reiser
can find a valid email for Jim. There was another guy who was Jim
Mostek's peer. I might have the name wrong.
Andrea Arcangeli
that needs the fs to handle zillons of tiny files, for that reiser3
did a good job, and my humble opinion is that the only chance for
reiser4 to stabilize is to grow the userbase and including it in
mainline or in some distro would obviously help (like it happened to
reiser3 in the past with SUSE inclusion first and mainline inclusion
later, nothing has changed dramatically since then, reiser3 was very
buggy at the time too, it was probably my backport of lfs that made us
notice it couldn't even handle lfs on-disk so they had to change the
fs format later on with some backwards compatibility mess with older
kernels, hopefully this time the fixage of v4 for production usage
won't require a change of the on-disk format).
On Mon, Jul 24, 2006 at 11:49:43AM +0400, Nikita Danilov wrote:
> Any data backing up that estimation? Just to give an example, that
Probably KLive is the only tool that can provide an estimate of the
part of the reiser4 userbase compared to the other fs. reiser4 had so
far 1926 days of total uptime and 4409 users using it at least once
for root or anyway mounted nearly at boot. Avg uptime is 16 hours, max
uptime is 28 days.
I can also provide the exact storage scsi/SATA/ATA chipsets used in
combination with it, but it doesn't seem necessary.
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where f = 'reiser4' group by f order by sum(uptime) desc;
f | count | sum | avg | max
----------------------------------+-------+------------------------------+-----------------+------------------
reiser4 | 4409 | 1926 days 27479:22:27.459534 | 16:42:59.666015 | 28 days 16:16:15
(1 row)
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where f = 'ext4' group by f order by sum(uptime) desc;
f | count | sum | avg | max
---+-------+-----+-----+-----
(0 rows)
klive=>
Full data of all fs (all kernels not just mainline ones) follows. In
total uptime and avg uptime terms it beats many other common fs like
isofs, autofs and ramfs. It'd be cool if I'd be able to receive a
packet during sigterm so I could then differentiate sessions that
rebooted cleanly from the ones that didn't. Receiving oopses
(optionally encrypted) is also a long term planned feature. At the
moment I can't (and I've no much time to work on klive), but this is
still good to quantify the current userbase compared to the other more
common fs.
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive group by f order by sum(uptime) desc;
f | count | sum | avg | max
----------------------------------+-------+--------------------------------+-------------------------+-------------------------
sysfs | 40998 | 35138 days 259797:16:29.93576 | 26:54:23.100394 | 173 days 16:16:15
tmpfs | 40507 | 35025 days 257298:57:48.690973 | 27:06:14.154311 | 173 days 16:16:15
usbfs | 38803 | 26681 days 241169:00:36.268676 | 22:43:03.543444 | 173 days 16:16:15
reiserfs | 19934 | 19257 days 133294:48:27.256508 | 29:52:18.181361 | 155 days 16:16:15
ext3 | 22077 | 16346 days 132190:42:38.862752 | 23:45:27.062502 | 173 days 16:16:15
ext2 | 9396 | 5629 days 63099:50:27.500173 | 21:05:37.103821 | 139 days 14:54:11
nfs | 2824 | 6373 days 23368:45:22.667638 | 2 days 14:26:11.502361 | 86 days 16:16:15
binfmt_misc | 4396 | 5421 days 33069:20:47.871638 | 1 day 13:07:06.944466 | 173 days 16:16:15
nfsd | 2231 | 4727 days 19824:00:00.354481 | 2 days 11:44:11.187967 | 89 days 16:16:15
xfs | 4326 | 4067 days 28000:38:11.762818 | 29:02:08.685105 | 139 days 14:54:11
vfat | 8684 | 2470 days 46585:39:49.859957 | 12:11:27.193673 | 68 days 16:16:15
ntfs | 8482 | 2382 days 47344:00:52.902741 | 12:19:17.846369 | 68 days 16:16:15
rpc_pipefs | 1188 | 3078 days 11297:55:12.600343 | 2 days 23:41:30.667172 | 173 days 16:16:15
reiser4 | 4409 | 1926 days 27479:22:27.459534 | 16:42:59.666015 | 28 days 16:16:15
^^^^^^^^^^^^^
autofs | 2030 | 2374 days 14512:14:16.617646 | 1 day 11:12:57.170748 | 54 days 16:16:15
ramfs | 2847 | 817 days 14809:30:42.122875 | 12:05:20.562741 | 32 days 16:16:15
selinuxfs | 600 | 1006 days 3466:41:58.91087 | 1 day 22:01:04.198185 | 173 days 16:16:15
smbfs | 222 | 1053 days 2155:11:48.374153 | 4 days 27:32:45.353037 | 122 days 16:20:01
jfs | 370 | 971 days 2435:07:17.805929 | 2 days 21:33:54.696773 | 160 days 16:16:15
iso9660 | 651 | 792 days 4698:41:27.153665 | 1 day 12:24:56.90807 | 84 days 16:06:15
subfs | 611 | 736 days 3482:38:06.342656 | 1 day 10:36:35.558662 | 122 days 16:20:01
devfs | 51 | 713 days 543:13:20.51142 | 13 days 34:10:50.99042 | 155 days 16:16:15
supermount | 260 | 437 days 1281:43:13.500606 | 1 day 21:16:05.359618 | 68 days 16:16:15
cifs | 506 | 222 days 2997:17:59.130448 | 16:27:11.381681 | 35 days 16:16:15
openpromfs | 53 | 296 days 631:17:42.10027 | 5 days 25:56:56.266043 | 43 days 16:16:15
fuse | 390 | 163 days 2443:31:37.846769 | 16:17:46.404735 | 17 days 16:16:15
squashfs | 62 | 198 days 622:55:15.099784 | 3 days 14:41:32.179029 | 34 days 16:16:15
configfs | 45 | 160 days 504:05:40.811143 | 3 days 24:32:07.573581 | 23 days 16:16:15
capifs | 67 | 135 days 569:04:11.286495 | 2 days 08:51:06.437112 | 39 days 16:16:15
minix | 35 | 128 days 428:57:59 | 3 days 28:01:39.40 | 16 days 16:16:15
cramfs | 6 | 140 days 69:58:03.269142 | 23 days 19:39:40.544857 | 58 days 16:16:15
udf | 15 | 102 days 161:35:54.111551 | 6 days 29:58:23.607437 | 51 days 16:16:15
debugfs | 314 | 39 days 1144:50:09.253475 | 06:37:36.717368 | 11 days 16:14:23.049312
ufs | 146 | 24 days 884:40:35.839055 | 10:00:16.683829 | 10 days 16:16:11.062917
usbdevfs | 139 | 1076:04:34.054012 | 07:44:29.597511 | 19:39:58
shm | 139 | 1076:04:34.054012 | 07:44:29.597511 | 19:39:58
hfsplus | 80 | 14 days 480:38:46.186027 | 10:12:29.077325 | 2 days 23:36:48
unionfs | 23 | 24 days 129:38:06 | 1 day 06:40:47.217391 | 22 days 16:16:15
ocfs2_dlmfs | 1 | 23 days 16:16:15 | 23 days 16:16:15 | 23 days 16:16:15
oprofilefs | 1 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967
nfs4 | 5 | 20 days 71:36:00 | 4 days 14:19:12 | 12 days 16:16:15
nnpfs | 9 | 18 days 78:16:50 | 2 days 08:41:52.222222 | 8 days 16:16:15
afs | 1 | 19 days 16:16:15 | 19 days 16:16:15 | 19 days 16:16:15
securityfs | 9 | 4 days 22:13:22 | 13:08:09.111111 | 4 days 16:16:15
ufsd | 15 | 75:38:57 | 05:02:35.80 | 23:01:05
vmware-hgfs | 1 | 1 day 04:56:21 | 1 day 04:56:21 | 1 day 04:56:21
shfs | 2 | 14:46:00 | 07:23:00 | 11:27:35
(47 rows)
Now let's eliminate from the screen all sessions that rebooted (or
crashed) in less than one day:
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where uptime > '1 day' group by f order by sum(uptime) desc;
f | count | sum | avg | max
----------------------------------+-------+-------------------------------+-------------------------+-------------------------
sysfs | 5385 | 35138 days 80491:02:11.763381 | 6 days 27:33:04.202742 | 173 days 16:16:15
tmpfs | 5344 | 35025 days 79890:55:31.804764 | 6 days 28:14:51.192329 | 173 days 16:16:15
usbfs | 4681 | 26681 days 69552:08:46.865054 | 5 days 31:39:17.301189 | 173 days 16:16:15
reiserfs | 2959 | 19257 days 44003:36:16.956207 | 6 days 27:03:42.161864 | 155 days 16:16:15
ext3 | 2520 | 16346 days 37501:47:54.627011 | 6 days 26:33:28.283582 | 173 days 16:16:15
nfs | 645 | 6373 days 10050:19:24.173861 | 9 days 36:43:00.409572 | 86 days 16:16:15
ext2 | 1012 | 5629 days 15173:13:30.06032 | 5 days 28:29:14.555396 | 139 days 14:54:11
binfmt_misc | 806 | 5421 days 12168:47:27.060755 | 6 days 32:31:01.59685 | 173 days 16:16:15
nfsd | 634 | 4727 days 9800:42:01.958542 | 7 days 26:23:54.892679 | 89 days 16:16:15
xfs | 607 | 4067 days 9311:21:11.733095 | 6 days 32:08:38.075343 | 139 days 14:54:11
rpc_pipefs | 445 | 3078 days 6789:18:13.704195 | 6 days 37:15:40.884729 | 173 days 16:16:15
vfat | 669 | 2470 days 9424:11:09.850314 | 3 days 30:41:48.624589 | 68 days 16:16:15
ntfs | 636 | 2382 days 9081:10:26.573867 | 3 days 32:09:55.324802 | 68 days 16:16:15
autofs | 405 | 2374 days 6335:32:22.311385 | 5 days 36:19:29.240275 | 54 days 16:16:15
reiser4 | 509 | 1926 days 7617:09:58.618041 | 3 days 33:46:41.961921 | 28 days 16:16:15
^^^^^^^^^^
smbfs | 96 | 1053 days 1476:55:37.466481 | 10 days 38:38:04.765276 | 122 days 16:20:01
selinuxfs | 97 | 1006 days 1584:22:47.021437 | 10 days 25:14:27.701252 | 173 days 16:16:15
jfs | 71 | 971 days 1070:04:09.186991 | 13 days 31:17:48.298408 | 160 days 16:16:15
ramfs | 241 | 817 days 3394:18:10.874752 | 3 days 23:26:42.8667 | 32 days 16:16:15
iso9660 | 85 | 792 days 1321:54:28.689609 | 9 days 23:10:31.396348 | 84 days 16:06:15
subfs | 89 | 736 days 1346:31:28.394797 | 8 days 21:36:05.038144 | 122 days 16:20:01
devfs | 24 | 713 days 399:55:43.321687 | 29 days 33:39:49.30507 | 155 days 16:16:15
supermount | 34 | 437 days 466:58:54.119926 | 12 days 34:12:19.238821 | 68 days 16:16:15
openpromfs | 29 | 296 days 515:10:26.10027 | 10 days 22:43:48.486216 | 43 days 16:16:15
cifs | 39 | 222 days 622:53:46.261055 | 5 days 32:35:13.493873 | 35 days 16:16:15
squashfs | 23 | 198 days 410:38:26 | 8 days 32:27:45.478261 | 34 days 16:16:15
fuse | 36 | 163 days 534:27:25.006209 | 4 days 27:30:45.694617 | 17 days 16:16:15
configfs | 23 | 160 days 344:26:41.378742 | 6 days 37:55:56.581684 | 23 days 16:16:15
minix | 24 | 128 days 393:11:05 | 5 days 24:22:57.708333 | 16 days 16:16:15
cramfs | 4 | 140 days 66:29:40.119926 | 35 days 16:37:25.029981 | 58 days 16:16:15
capifs | 11 | 135 days 170:13:33 | 12 days 22:01:13.909091 | 39 days 16:16:15
udf | 4 | 102 days 64:26:53 | 25 days 28:06:43.25 | 51 days 16:16:15
debugfs | 11 | 39 days 182:23:03.211977 | 3 days 29:40:16.655634 | 11 days 16:14:23.049312
ufs | 11 | 24 days 151:36:11.289322 | 2 days 18:08:44.662666 | 10 days 16:16:11.062917
unionfs | 2 | 24 days 39:53:03 | 12 days 19:56:31.50 | 22 days 16:16:15
ocfs2_dlmfs | 1 | 23 days 16:16:15 | 23 days 16:16:15 | 23 days 16:16:15
oprofilefs | 1 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967
nfs4 | 4 | 20 days 62:33:56 | 5 days 15:38:29 | 12 days 16:16:15
nnpfs | 4 | 18 days 73:50:18 | 4 days 30:27:34.50 | 8 days 16:16:15
afs | 1 | 19 days 16:16:15 | 19 days 16:16:15 | 19 days 16:16:15
hfsplus | 11 | 14 days 109:35:09 | 1 day 16:30:28.090909 | 2 days 23:36:48
securityfs | 1 | 4 days 16:16:15 | 4 days 16:16:15 | 4 days 16:16:15
vmware-hgfs | 1 | 1 day 04:56:21 | 1 day 04:56:21 | 1 day 04:56:21
(43 rows)
Now let's eliminate everything that rebooted or crashed in less than 10 days:
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where uptime > '10 day' group by f order by sum(uptime) desc;
f | count | sum | avg | max
----------------------------------+-------+-------------------------------+-------------------------+-------------------------
sysfs | 948 | 22969 days 15224:50:33.717548 | 24 days 21:33:13.073542 | 173 days 16:16:15
tmpfs | 949 | 22960 days 15240:45:20.729486 | 24 days 20:42:47.250505 | 173 days 16:16:15
usbfs | 689 | 16015 days 11048:34:25.54762 | 23 days 21:53:15.450722 | 173 days 16:16:15
reiserfs | 516 | 12330 days 8297:16:33.102261 | 23 days 37:34:06.110663 | 155 days 16:16:15
ext3 | 453 | 10925 days 7258:04:40.240741 | 24 days 18:49:48.698103 | 173 days 16:16:15
nfs | 193 | 4902 days 3138:54:10.459336 | 25 days 25:50:19.950567 | 86 days 16:16:15
binfmt_misc | 154 | 3581 days 2484:52:11.438999 | 23 days 22:12:48.385968 | 173 days 16:16:15
ext2 | 139 | 3359 days 2218:31:49.225427 | 24 days 19:55:54.742629 | 139 days 14:54:11
nfsd | 135 | 3226 days 2186:35:50.40609 | 23 days 37:42:29.262267 | 89 days 16:16:15
xfs | 116 | 2666 days 1848:31:20.130065 | 22 days 39:31:18.276983 | 139 days 14:54:11
rpc_pipefs | 84 | 2034 days 1356:31:00.312955 | 24 days 21:17:30.718011 | 173 days 16:16:15
autofs | 69 | 1366 days 1095:10:03.052435 | 19 days 35:00:08.73989 | 54 days 16:16:15
ntfs | 56 | 1058 days 905:01:16.41019 | 18 days 37:35:22.793039 | 68 days 16:16:15
vfat | 52 | 1060 days 846:41:12.168038 | 20 days 25:30:47.541693 | 68 days 16:16:15
reiser4 | 53 | 820 days 859:44:03.65926 | 15 days 27:32:31.767156 | 28 days 16:16:15
^^^^^^^^^^^^
jfs | 21 | 837 days 336:58:57 | 39 days 36:37:05.571429 | 160 days 16:16:15
smbfs | 30 | 815 days 475:06:57.099919 | 27 days 19:50:13.903331 | 122 days 16:20:01
selinuxfs | 28 | 767 days 454:42:21.021437 | 27 days 25:40:05.03648 | 173 days 16:16:15
devfs | 14 | 686 days 233:05:03.154639 | 49 days 16:38:55.939617 | 155 days 16:16:15
iso9660 | 24 | 596 days 386:04:44.125293 | 24 days 36:05:11.838554 | 84 days 16:06:15
subfs | 20 | 542 days 306:50:12.359485 | 27 days 17:44:30.617974 | 122 days 16:20:01
supermount | 13 | 383 days 210:20:37.087554 | 29 days 27:15:25.929812 | 68 days 16:16:15
ramfs | 17 | 327 days 261:34:11.310952 | 19 days 21:02:00.66535 | 32 days 16:16:15
openpromfs | 13 | 238 days 211:24:12.08448 | 18 days 23:38:47.083422 | 43 days 16:16:15
squashfs | 8 | 142 days 130:10:00 | 17 days 34:16:15 | 34 days 16:16:15
cramfs | 3 | 137 days 48:48:44.087554 | 45 days 32:16:14.695851 | 58 days 16:16:15
cifs | 6 | 115 days 97:37:30 | 19 days 20:16:15 | 35 days 16:16:15
capifs | 4 | 116 days 65:05:00 | 29 days 16:16:15 | 39 days 16:16:15
configfs | 5 | 95 days 80:52:24.077093 | 19 days 16:10:28.815419 | 23 days 16:16:15
udf | 3 | 96 days 48:10:38 | 32 days 16:03:32.666667 | 51 days 16:16:15
fuse | 6 | 85 days 93:19:29 | 14 days 19:33:14.833333 | 17 days 16:16:15
minix | 3 | 42 days 48:48:45 | 14 days 16:16:15 | 16 days 16:16:15
ocfs2_dlmfs | 1 | 23 days 16:16:15 | 23 days 16:16:15 | 23 days 16:16:15
oprofilefs | 1 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967
unionfs | 1 | 22 days 16:16:15 | 22 days 16:16:15 | 22 days 16:16:15
afs | 1 | 19 days 16:16:15 | 19 days 16:16:15 | 19 days 16:16:15
nfs4 | 1 | 12 days 16:16:15 | 12 days 16:16:15 | 12 days 16:16:15
debugfs | 1 | 11 days 16:14:23.049312 | 11 days 16:14:23.049312 | 11 days 16:14:23.049312
ufs | 1 | 10 days 16:16:11.062917 | 10 days 16:16:11.062917 | 10 days 16:16:11.062917
(39 rows)
klive=>
Now let's eliminate everything that rebooted or crashed in less than 20 days:
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where uptime > '20 day' group by f order by sum(uptime) desc;
f | count | sum | avg | max
----------------------------------+-------+------------------------------+-------------------------+-------------------------
sysfs | 425 | 15940 days 6844:38:13.264145 | 37 days 28:14:46.337092 | 173 days 16:16:15
tmpfs | 425 | 15908 days 6844:19:50.221708 | 37 days 26:26:18.329933 | 173 days 16:16:15
usbfs | 266 | 10341 days 4258:02:54.770525 | 38 days 37:01:48.927709 | 173 days 16:16:15
reiserfs | 236 | 8553 days 3809:00:57.232965 | 36 days 21:56:11.428953 | 155 days 16:16:15
ext3 | 197 | 7465 days 3163:26:12.784865 | 37 days 37:29:58.846624 | 173 days 16:16:15
nfs | 127 | 4029 days 2066:09:04.104158 | 31 days 33:39:17.04019 | 86 days 16:16:15
binfmt_misc | 63 | 2318 days 1020:40:19.272961 | 36 days 35:14:55.544015 | 173 days 16:16:15
nfsd | 63 | 2243 days 1023:44:21.136625 | 35 days 30:43:33.668835 | 89 days 16:16:15
ext2 | 53 | 2220 days 827:52:02.580825 | 41 days 36:54:11.36945 | 139 days 14:54:11
xfs | 42 | 1665 days 662:12:10.297862 | 39 days 31:11:43.10233 | 139 days 14:54:11
rpc_pipefs | 30 | 1286 days 486:09:06.068985 | 42 days 37:00:18.202299 | 173 days 16:16:15
autofs | 23 | 756 days 374:13:45 | 32 days 37:08:25.434783 | 54 days 16:16:15
jfs | 10 | 677 days 158:20:12 | 67 days 32:38:01.20 | 160 days 16:16:15
vfat | 20 | 636 days 326:41:41.13894 | 31 days 35:32:05.056947 | 68 days 16:16:15
smbfs | 15 | 620 days 231:13:12.099919 | 41 days 23:24:52.806661 | 122 days 16:20:01
devfs | 9 | 609 days 151:46:53.100264 | 67 days 32:51:52.566696 | 155 days 16:16:15
ntfs | 20 | 584 days 325:04:00.023183 | 29 days 21:03:12.001159 | 68 days 16:16:15
selinuxfs | 9 | 485 days 145:33:36.021437 | 53 days 37:30:24.002382 | 173 days 16:16:15
iso9660 | 13 | 463 days 207:52:24 | 35 days 30:45:34.153846 | 84 days 16:06:15
subfs | 10 | 403 days 144:54:16.30619 | 40 days 21:41:25.630619 | 122 days 16:20:01
supermount | 9 | 325 days 145:38:07.087554 | 36 days 18:50:54.120839 | 68 days 16:16:15
ramfs | 10 | 249 days 147:43:34.143084 | 24 days 36:22:21.414308 | 32 days 16:16:15
reiser4 | 10 | 240 days 161:33:44.187484 | 24 days 16:09:22.418748 | 28 days 16:16:15
^^^^^^^^^^^^^
cramfs | 3 | 137 days 48:48:44.087554 | 45 days 32:16:14.695851 | 58 days 16:16:15
openpromfs | 5 | 130 days 81:21:15 | 26 days 16:16:15 | 43 days 16:16:15
capifs | 3 | 102 days 48:48:45 | 34 days 16:16:15 | 39 days 16:16:15
udf | 3 | 96 days 48:10:38 | 32 days 16:03:32.666667 | 51 days 16:16:15
cifs | 3 | 81 days 48:48:45 | 27 days 16:16:15 | 35 days 16:16:15
squashfs | 3 | 79 days 48:48:45 | 26 days 24:16:15 | 34 days 16:16:15
configfs | 3 | 64 days 48:28:45 | 21 days 24:09:35 | 23 days 16:16:15
ocfs2_dlmfs | 1 | 23 days 16:16:15 | 23 days 16:16:15 | 23 days 16:16:15
oprofilefs | 1 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967 | 23 days 16:16:08.088967
unionfs | 1 | 22 days 16:16:15 | 22 days 16:16:15 | 22 days 16:16:15
(33 rows)
klive=>
Currently the number of reiser4 users is 35, this lists only the
kernels running in real time as I write this that are running reiser4:
klive=> select f, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where last + '1 day' > 'now' group by f order by sum(uptime) desc;
f | count | sum | avg | max
----------------------------------+-------+-----------------------------+-------------------------+-------------------------
sysfs | 484 | 3928 days 4530:39:11.52799 | 8 days 12:08:15.76762 | 173 days 16:16:15
tmpfs | 480 | 3927 days 4501:01:21.406313 | 8 days 13:43:37.669596 | 173 days 16:16:15
usbfs | 437 | 2903 days 3824:39:39.983599 | 6 days 24:11:04.485088 | 173 days 16:16:15
ext3 | 279 | 2053 days 2355:05:46.852916 | 7 days 17:02:36.08191 | 173 days 16:16:15
reiserfs | 230 | 1949 days 2245:30:53.639863 | 8 days 21:08:13.276695 | 155 days 16:16:15
xfs | 58 | 624 days 587:32:09.569396 | 10 days 28:20:12.578783 | 139 days 14:54:11
ext2 | 91 | 608 days 933:47:49.912624 | 6 days 26:36:47.361677 | 139 days 14:54:11
binfmt_misc | 58 | 600 days 619:39:09.233036 | 10 days 18:57:34.297121 | 173 days 16:16:15
nfsd | 32 | 546 days 420:58:29.048813 | 17 days 14:39:19.657775 | 89 days 16:16:15
jfs | 10 | 546 days 143:40:39 | 54 days 28:46:03.90 | 160 days 16:16:15
nfs | 28 | 518 days 380:48:49.210675 | 18 days 25:36:01.757524 | 64 days 16:16:15
rpc_pipefs | 25 | 473 days 347:10:34.048813 | 18 days 35:58:01.361953 | 173 days 16:16:15
autofs | 17 | 211 days 218:50:13.090969 | 12 days 22:45:18.417116 | 54 days 16:16:15
selinuxfs | 10 | 204 days 105:21:47 | 20 days 20:08:10.70 | 173 days 16:16:15
devfs | 3 | 193 days 48:35:34.022351 | 64 days 24:11:51.340784 | 155 days 16:16:15
ntfs | 74 | 93 days 459:41:24.880971 | 1 day 12:22:27.092986 | 30 days 16:16:15
vfat | 64 | 83 days 437:49:49.197282 | 1 day 13:57:57.956208 | 37 days 16:16:15
iso9660 | 16 | 90 days 126:40:31.377898 | 5 days 22:55:01.961119 | 75 days 13:45:31
smbfs | 7 | 72 days 122:03:20 | 10 days 24:17:37.142857 | 27 days 16:16:15
reiser4 | 35 | 56 days 314:41:54.194701 | 1 day 23:23:28.976991 | 24 days 16:16:15
^^^^^^^^^^^^^^^
udf | 1 | 51 days 16:16:15 | 51 days 16:16:15 | 51 days 16:16:15
ramfs | 11 | 45 days 82:10:59.027323 | 4 days 09:39:10.820666 | 30 days 16:16:15
configfs | 2 | 24 days 25:15:41 | 12 days 12:37:50.50 | 22 days 16:06:15
squashfs | 1 | 21 days 16:16:15 | 21 days 16:16:15 | 21 days 16:16:15
subfs | 2 | 20 days 18:08:18.063223 | 10 days 09:04:09.031611 | 20 days 16:15:43.063223
cifs | 6 | 15 days 66:54:31 | 2 days 23:09:05.166667 | 11 days 16:16:15
openpromfs | 3 | 14 days 61:21:33.08448 | 4 days 36:27:11.02816 | 11 days 16:09:12.08448
fuse | 4 | 10 days 34:01:09 | 2 days 20:30:17.25 | 8 days 16:16:15
debugfs | 6 | 9 days 46:25:01 | 1 day 19:44:10.166667 | 8 days 16:16:15
minix | 1 | 8 days 16:16:15 | 8 days 16:16:15 | 8 days 16:16:15
hfsplus | 1 | 1 day 12:20:26 | 1 day 12:20:26 | 1 day 12:20:26
ufs | 7 | 10:55:17 | 01:33:36.714286 | 04:18:01
supermount | 2 | 03:14:39 | 01:37:19.50 | 01:52:35
securityfs | 1 | 00:38:07 | 00:38:07 | 00:38:07
(34 rows)
klive=>
And these are the respective kernel versions:
klive=> select kernel_release, count(*), sum(uptime), avg(uptime), max(uptime) from fs natural inner join klive where last + '1 day' > 'now' and f = 'reiser4' group by kernel_release order by sum(uptime) desc;
kernel_release | count | sum | avg | max
-------------------------+-------+------------------------+------------------------+------------------------
2.6.17-ckpp1 | 1 | 24 days 16:16:15 | 24 days 16:16:15 | 24 days 16:16:15
2.6.17-beyond2 | 3 | 9 days 61:26:13.021287 | 3 days 20:28:44.340429 | 6 days 16:13:52.021287
2.6.15-gentoo-r1-blip-1 | 1 | 10 days 16:16:15 | 10 days 16:16:15 | 10 days 16:16:15
2.6.16-gentoo-r12 | 1 | 6 days 16:06:15 | 6 days 16:06:15 | 6 days 16:06:15
2.6.17-beyond1.1 | 1 | 3 days 17:41:00 | 3 days 17:41:00 | 3 days 17:41:00
2.6.16-reiser4-r7 | 1 | 2 days 08:58:55.041969 | 2 days 08:58:55.041969 | 2 days 08:58:55.041969
2.6.18-rc1-mm2-non14 | 1 | 1 day 21:35:33 | 1 day 21:35:33 | 1 day 21:35:33
2.6.17-no4 | 1 | 1 day 04:56:21 | 1 day 04:56:21 | 1 day 04:56:21
2.6.17-beyond2.1 | 2 | 24:53:40 | 12:26:50 | 23:01:05
2.6.16-beyond4.1 | 1 | 22:51:05 | 22:51:05 | 22:51:05
2.6.17-PRX5.1 | 2 | 18:16:52 | 09:08:26 | 18:16:52
2.6.18-rc1-mm2 | 1 | 18:16:52 | 18:16:52 | 18:16:52
2.6.17-gentoo-r3 | 3 | 11:02:11 | 03:40:43.666667 | 07:05:39
2.6.17-rc1-no2 | 2 | 10:24:03.045926 | 05:12:01.522963 | 07:05:39
2.6.17-beyond1 | 1 | 09:02:04 | 09:02:04 | 09:02:04
2.6.17-beyond-git2 | 1 | 09:02:04 | 09:02:04 | 09:02:04
2.6.16-beyond3 | 1 | 07:05:39 | 07:05:39 | 07:05:39
2.6.17-no1 | 3 | 06:33:04 | 02:11:01.333333 | 03:18:25
2.6.17-beyond2-r2 | 1 | 05:22:31 | 05:22:31 | 05:22:31
2.6.17-gentoo-r4 | 1 | 04:18:01 | 04:18:01 | 04:18:01
2.6.16-beyond4 | 3 | 03:19:24.068344 | 01:06:28.022781 | 03:09:24.068344
2.6.17-reiser4-r4 | 2 | 00:57:37.017176 | 00:28:48.508588 | 00:57:37.017176
2.6.16-reiser4-r11 | 1 | 00:00:00 | 00:00:00 | 00:00:00
(23 rows)
klive=>
This is the whole list of kernel_releases that ever run reiser4:
kernel_release | count | sum | avg | max
-------------------------------------+-------+-------------------------------+--------------------------+--------------------------
2.6.15-gentoo-r1 | 15726 | 12498 days 94186:27:26.881778 | 25:03:46.27794 | 139 days 14:54:11
2.6.15.6 | 262 | 6192 days 4014:29:48.915128 | 23 days 30:31:43.011126 | 114 days 16:16:15
2.6.16-gentoo-r7 | 5893 | 3852 days 34120:33:11.729484 | 21:28:40.005384 | 35 days 16:11:20.052466
2.6.16-gentoo-r9 | 7349 | 3505 days 39841:34:06.868008 | 16:52:04.132109 | 45 days 16:16:15
2.6.14-gentoo-r5 | 3363 | 3774 days 25871:49:28.023204 | 1 day 10:37:34.22778 | 85 days 16:16:15
2.6.16-rc5 | 1309 | 3909 days 10877:31:17.420649 | 2 days 31:58:47.179084 | 42 days 16:16:15
2.6.15-gentoo-r7 | 4183 | 2741 days 25823:28:50.761387 | 21:53:59.811322 | 48 days 16:10:16.072702
2.6.16-gentoo-r8 | 3300 | 2737 days 21674:06:24.528491 | 26:28:24.116524 | 55 days 16:16:15
2.6.16-gentoo-r3 | 4780 | 2369 days 26106:57:10.720939 | 17:21:22.558728 | 91 days 16:16:15
2.6.16-gentoo-r2 | 2303 | 2600 days 17412:40:17.134521 | 1 day 10:39:21.449038 | 89 days 16:16:15
2.6.15.1 | 1463 | 2818 days 10447:34:09.563652 | 1 day 29:22:10.177419 | 136 days 16:16:15
2.6.16-gentoo-r1 | 3608 | 2233 days 21934:44:07.471825 | 20:55:59.270364 | 64 days 16:03:18.045239
2.6.16 | 1165 | 2508 days 9354:44:26.049247 | 2 days 11:41:48.382875 | 53 days 16:06:15
2.6.16-gentoo-r6 | 2075 | 2300 days 13980:21:11.200159 | 1 day 09:20:23.745157 | 58 days 16:16:15
2.6.15-gentoo-r5 | 3321 | 1909 days 17474:22:48.504908 | 19:03:27.458147 | 104 days 16:15:50.041517
2.6.17-gentoo | 3291 | 1753 days 19508:59:15.100422 | 18:42:42.97633 | 30 days 16:16:15
2.6.17-rc1 | 785 | 2053 days 8234:01:41.533576 | 2 days 25:15:21.912782 | 69 days 16:16:15
2.6.15 | 2206 | 1673 days 14112:53:10.800042 | 24:35:55.571532 | 45 days 16:16:15
2.6.15-gentoo | 3284 | 1260 days 20322:09:18.149661 | 15:23:47.453761 | 26 days 16:16:15
2.6.16-beyond4 | 2123 | 1268 days 15252:17:49.21025 | 21:31:07.484319 | 21 days 16:16:15
2.6.16-archck1 | 1330 | 1388 days 10490:30:49.827973 | 1 day 08:56:03.195359 | 36 days 16:16:15
2.6.15.4 | 302 | 1683 days 2958:42:00.940999 | 5 days 23:32:43.314374 | 80 days 16:16:15
2.6.12-12mdk | 360 | 1630 days 3696:44:27.785247 | 4 days 22:56:07.410515 | 84 days 16:06:15
2.6.15-ck3-r1 | 769 | 1364 days 6171:30:41.606372 | 1 day 26:35:41.796627 | 43 days 16:16:15
2.6.15-nitro3 | 1709 | 1142 days 10979:07:40.254166 | 22:27:42.293888 | 31 days 16:16:15
2.6.16-beyond3 | 1806 | 1030 days 13334:56:02.827243 | 21:04:17.011532 | 22 days 16:14:05.037859
2.6.15-ck7 | 637 | 1357 days 5372:37:06.322867 | 2 days 11:33:41.07743 | 31 days 16:16:15
2.6.9-22.0.1.ELsmp | 13 | 1571 days 211:31:15 | 120 days 36:34:42.692308 | 173 days 16:16:15
2.6.15-archck | 2579 | 865 days 15948:06:33.240877 | 14:14:00.478186 | 28 days 16:16:15
2.6.15-1-k7 | 164 | 1376 days 2179:27:47.995174 | 8 days 22:39:18.95119 | 35 days 16:16:15
2.6.16-ck11 | 1402 | 1016 days 10372:57:34.350942 | 24:47:27.542333 | 39 days 16:14:38.079596
2.6.16-gentoo | 1927 | 942 days 11516:24:54.920025 | 17:42:30.853617 | 47 days 16:16:15
2.6.14.5 | 169 | 1318 days 1681:33:11 | 7 days 29:07:17.816568 | 86 days 16:16:15
2.6.16-ck10 | 814 | 1130 days 5987:58:35.725072 | 1 day 16:40:23.483692 | 40 days 16:16:15
2.6.14-hardened-r5 | 636 | 1194 days 4394:03:05.986415 | 1 day 27:57:55.76413 | 52 days 16:16:15
2.6.12-gentoo-r10 | 300 | 1213 days 3756:26:28.092538 | 4 days 13:33:41.293642 | 89 days 16:16:15
2.6.17 | 1038 | 918 days 10628:20:44.642394 | 31:27:52.875378 | 32 days 16:04:49.04156
2.6.16-ck3 | 1043 | 1053 days 6467:18:14.426646 | 1 day 06:25:50.809613 | 54 days 16:16:15
2.6.16.1 | 314 | 1161 days 3632:43:26.24459 | 3 days 28:18:28.937085 | 67 days 16:16:15
2.6.15-archck2 | 1738 | 727 days 12587:25:00.214091 | 17:16:53.751562 | 14 days 16:16:15
2.6.13-gentoo-r5 | 880 | 833 days 9688:10:28.922616 | 33:43:38.896503 | 34 days 16:16:15
2.6.15-ck2pwr | 92 | 1127 days 1357:25:27.655134 | 12 days 20:45:16.604947 | 52 days 16:16:15
[..]
too long to list them all.
> "patchup" is used by (tens of) thousands of computers in governmental
> laboratories the US "national security" depends upon.
I don't see any ext4 in the klive logs, it'd be nice if I would know
how to track your ext4 patchset too to make a more accurate
comparison. We can't compare the above numbers to the klive ones, the
above is the interpolation of the reiser4 and klive userbase
only. While if I could detect the ext4 "patchup" it would be feasible
to attempt a comparison.
Disclaimer: the data should not be trusted, use it at your
risk. Furthermore it may not represent a reliable sample, because the
fs are only submitted at the first connection with the server after
reboot, so if reiser4 or fuse are mounted later on (normally after an
average of 5 minutes) they may not get logged in KLive. OTOH this also
means that all computers showing reiser4 in the logs had it mounted
since about the boot time (so if reiser4 would corrupt memory badly by
just mounting nobody could reasonably hope to reach 20 days of
uptime).
Hope this helps.
Rene Rebe
On Tuesday 25 July 2006 14:35, Andrea Arcangeli wrote:
...
> average of 5 minutes) they may not get logged in KLive. OTOH this also
> means that all computers showing reiser4 in the logs had it mounted
> since about the boot time (so if reiser4 would corrupt memory badly by
> just mounting nobody could reasonably hope to reach 20 days of
> uptime).
Well I tested Reiser4 on systems building our Linux flavour (based on the T2
framework) thus with excessive software compilation, a lot of tarball
extraction, compilation of fat packages such as linux, mozilla, openoffice
et.al. and huge per-package ccache directories -> zilions of small files and
did not encounter any abnormal behaviour aside the yet-to-be-fixed commit
storms. Performance was superiour over ext3, XFS*, JFS or Reiser3 in this
workload (that is less time "wasted" for FS housekeeping and the build
finished noticable earlier). Patchset was tested around 2.6.1{4,5]. But I do
not have the numbers around anymore and was basically waiting for Reiser4 to
make it into the kernel to schedule further testing.
You can see I'm not a blind Reiser4 follower but would rather like to see a
fair chance for it.
*) XFS oopsed so often in this test that I'll never touch it again ...
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
Denis Vlasenko
> > Once the inodes ran out the entire system pretty much came to a
> > screeching halt.
>
> Get a clue by for, apply to the vendor (for the design, or at the very
> least for not warning unsuspecting users)?
>
> > We basically had two options, use ReiserFS, or find
> > another piece of software that didn't use tiny little files as its
> > database.
>
> Or reconfigure the filesystem with more inodes (you were willing to rebuild
> the filesystem in any case, so...)
The fact that _many_ UNIX filesystem formats have inode number limit
(configurable only at mkfs time) doesn't make it a good design.
By the same virtue you may declare that it is okay to smoke
and drink lots of vodka. Why not? Sizable portion if population does that...
I, on the contrary, want software to impose as few limits on me
as possible.
--
vda
Hans Reiser
of ext3. I mean, you can't even get a distro which allows you to
install onto reiser4 without hours of work so far as I know. I guess
there are people who really do care about twice as fast.
Hans
Andrea Arcangeli wrote:
> reiserfs | 19934 | 19257 days 133294:48:27.256508 | 29:52:18.181361 | 155 days 16:16:15
> ext3 | 22077 | 16346 days 132190:42:38.862752 | 23:45:27.062502 | 173 days 16:16:15
>
> reiser4 | 4409 | 1926 days 27479:22:27.459534 | 16:42:59.666015 | 28 days 16:16:15
>^^^^^^^^^^^^^
>
>
-
Russell Cattelan
> 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.
>
Which is summed up quite well by:
http://en.wikipedia.org/wiki/Color_of_the_bikeshed
It seem to be a well know tendency for people to want to
be involved in some way, thus keeping to much of the development
cycle internal tends to generate friction.
-Russell Cattelan
catt...@xfs.org
Francesco Biscani
> Wow, I would never have guessed our market share was that high as 1/5th
> of ext3. I mean, you can't even get a distro which allows you to
> install onto reiser4 without hours of work so far as I know. I guess
> there are people who really do care about twice as fast.
>
> Hans
>
Yes, this was a pleasant surprise indeed :)
This useless mail from a mere user is just to testify that I've used reiser4
on my laptop since June 2004, and that, barring occasional hiccups, I never
had serious problems with it. In fact I haven't lost a single bit of data
despite crashes and cold shutdowns due to power outage.
I don't know if this means something or if I've just been lucky, but it seems
to me that when reiser4 crashes (and sometimes it does, given its young age),
it behaves very very well. That's the thing that impressed me the most (and
it is really something, given for example the debacle of a mature filesystem
like XFS in 2.6.17). Oh, and performance, of course ;)
I really hope that the technical difficulties that are preventing reiser4 from
entering mainline will be sorted out soon.
Thanks,
Francesco (crawling back in the shadow)
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Università di Padova
bis...@pd.astro.it
Matthias Andree
> I, on the contrary, want software to impose as few limits on me
> as possible.
As long as it's choosing some limit, I'll pick the one with fewer
surprises.
--
Matthias Andree
Horst H. von Brand
> Wow, I would never have guessed our market share was that high as 1/5th
> of ext3. I mean, you can't even get a distro which allows you to
> install onto reiser4 without hours of work so far as I know. I guess
> there are people who really do care about twice as fast.
That makes the data /higly/ suspect: Most of the Linux users I know
wouldn't know where to start to compile a kernel, forget about patching
around. And of the minority who can, they mostly run machines in
production, and won't dream of using non-distribution kernels, let alone
custom patched ones.
BTW, where do you get the "twice as fast" number from?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
-
Valdis.K...@vt.edu
> 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
"forever"? Man, that's hard-core. Is that *really* the guideline, or is
it some "might as well be forever in this industry" rule like "5 years"?
Jim Crilly
> Hans Reiser <rei...@namesys.com> wrote:
> > Wow, I would never have guessed our market share was that high as 1/5th
> > of ext3. I mean, you can't even get a distro which allows you to
> > install onto reiser4 without hours of work so far as I know. I guess
> > there are people who really do care about twice as fast.
>
> That makes the data /higly/ suspect: Most of the Linux users I know
> wouldn't know where to start to compile a kernel, forget about patching
> around. And of the minority who can, they mostly run machines in
> production, and won't dream of using non-distribution kernels, let alone
> custom patched ones.
485 computers providing data. I'm not trying to knock Andrea's project, but
the sample size is quite small and only really representative of people who
would be inclined to read lkml, patch their kernels, etc.
Jim.
David Masover
> On Tue, 25 Jul 2006, Denis Vlasenko wrote:
>
>> I, on the contrary, want software to impose as few limits on me
>> as possible.
>
> As long as it's choosing some limit, I'll pick the one with fewer
> surprises.
Running out of inodes would be pretty surprising for me.
But then, I guess it's a good thing I don't admin for a living anymore.
Luigi Genoni
test system to play with.
Luigi
On Tuesday 25 July 2006 23:17, Horst H. von Brand wrote:
> Hans Reiser <rei...@namesys.com> wrote:
> > Wow, I would never have guessed our market share was that high as 1/5th
> > of ext3. I mean, you can't even get a distro which allows you to
> > install onto reiser4 without hours of work so far as I know. I guess
> > there are people who really do care about twice as fast.
>
> That makes the data /higly/ suspect: Most of the Linux users I know
> wouldn't know where to start to compile a kernel, forget about patching
> around. And of the minority who can, they mostly run machines in
> production, and won't dream of using non-distribution kernels, let alone
> custom patched ones.
>
> BTW, where do you get the "twice as fast" number from?
and...@cpushare.com
> Well if you take a look at the KLive webpage you'll see that there's only
> 485 computers providing data. I'm not trying to knock Andrea's project, but
> the sample size is quite small and only really representative of people who
> would be inclined to read lkml, patch their kernels, etc.
There are quite a few using the official distro kernels but the point
remains that the KLive users are probably the ones most interested to
try all new stuff and to live on the edge. They're not afraid to put
the new technologies to work for them. That's probably why they're
using reiser4 so much. OTOH they're probably the ones putting the fs
under the most stress, a regular desktop user not capable of running
klive.sh --install from the shell, would probably leave his CPU and
harddisk idle most of the time too.
Being this only a sample I can't come up with absolute figures, but
obviously there are more users than what is being recorded by KLive.
However the sample is not so small, in less then a year KLive logged
76740 days of uptime and 61355 reboots (or klive session restarts),
and like you noticed an average of about 400-500 systems are always
connected.
David Masover
> On Sun, 2006-07-23 at 01:20 -0600, Hans Reiser wrote:
>> 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
>> 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.
>>
> Which is summed up quite well by:
> http://en.wikipedia.org/wiki/Color_of_the_bikeshed
>
> It seem to be a well know tendency for people to want to
> be involved in some way, thus keeping to much of the development
> cycle internal tends to generate friction.
No, I think Hans is right.
Although I should mention, Hans, that there is a really good reason to
prefer the 15 minute patches. The patches that take a week are much
harder to read during that week than any number of 15 minute incremental
patches, because the incremental patches are already broken down into
nice, small, readable, ordered chunks. And since development follows
some sort of logical, orderly pattern, it can be much easier to read it
that way than to try to consider the whole.
Think of it this way -- why are debuggers useful? One of the nicest
thing about a debugger, especially for newbies, is the ability to step
through a program a line at a time. It's the same principle -- you can
understand the program state at one point in time, and the impact of one
line of code, much more easily than the overall model of the program
state (and all of its edge cases), or the impact of several hundred
(thousand? tens of thousands?) lines of code.
So while I don't blame the Namesys team for putting off inclusion till
it's done, I also can't really blame the kernel guys for not wanting to
read it, especially if it's revolutionary. Revolutionary ideas are hard
to grasp, and it's not their fault.
I mean, if revolutionary ideas were easy, why didn't you write Reiser4
for a system like, say, Tunes? (http://tunes.org/) Say what you will,
but there are ways of doing fast filesystems which don't require that
said filesystems be written in kernel C. Consider this:
http://www.cs.utah.edu/flux/oskit/
If I understand that right, it's a mechanism for writing kernel code in
languages like "Java, Lisp, Scheme, or ML"...
If we could all grasp every single good (best) idea from every corner of
software engineering, and write completely new software (including the
OS) using those ideas, we could potentially replace all existing
software in something like 3-5 years with software which has none of the
problems ours does now. We'd never have inflexibility, insecurity,
instability, user interface issues... Never have to worry about getting
software out the door (it'd be so fast to develop), but always have it
designed the right way the first time, yet be able to rearrange it
completely with only 5-10 line patches.
So it's not always the computer hardware that's the limitation. Often
it's our hardware as well. Human beings usually aren't equipped to be
able to grok the whole universe all at once. If we were... see above.
David Lang
> Horst H. von Brand wrote:
>
>> 18GiB = 18 million KiB, you do have a point there. But 40 million files on
>> that, with some space to spare, just doesn't add up.
if you have 18 million KiB and each file is a single block (512 Bytes = 0.5 Kib)
then assuming zero overhead you could fit 18 Million KiB / 0.5 KiB = 36 Million
files on the drive.
thus being scheptical about 40 million files on a 18G drive.
this is only possible if you are abel to have multiple files per 512 byte block.
David Lang
> Right, ok...
>
> Here's a quick check of my box. I've explicitly stated which root-level
> directories to search, to avoid nfs mounts, chrooted OSes, and virtual
> filesystems like /proc and /sys.
>
> elite ~ # find /bin/ /boot/ /dev/ /emul/ /etc/ /home /lib32 /lib64 /opt
> /root /sbin /tmp /usr /var -type f -size 1 | wc -l
> 246127
>
> According to the "find" manpage:
>
> -size n[bckw]
> File uses n units of space. The units are 512-byte blocks by
> default or if `b' follows n, bytes if `c' follows n, kilobytes
> if `k' follows n, or 2-byte words if `w' follows n. The size
> does not count indirect blocks, but it does count blocks in
> sparse files that are not actually allocated.
>
>
> And I certainly didn't plan it that way. And this is my desktop box,
> and I'm just one user. Most of the space is taken up by movies.
>
> And yet, I have almost 250k files at the moment whose size is less than
> 512 bytes. And this is a normal usage pattern. It's not hard to
> imagine something prone to creating lots of tiny files, combined with
> thousands of users, easily hitting some 40 mil files -- and since none
> of them are movies, it could fit in 18 gigs.
>
> I mean, just for fun:
>
> elite ~ # find /bin/ /boot/ /dev/ /emul/ /etc/ /home /lib32 /lib64 /opt
> /root /sbin /tmp /usr /var | wc -l
> 866160
>
> It may not be a good idea, but it's possible. And one of the larger
> reasons it's not a good idea is that most filesystems can't handle it.
> Kind of like how BitTorrent is a very bad idea on dialup, but a very
> good idea on broadband.
David Masover
> On Tue, 25 Jul 2006, David Masover wrote:
>
>> Horst H. von Brand wrote:
>>
>>> 18GiB = 18 million KiB, you do have a point there. But 40 million
>>> files on
>>> that, with some space to spare, just doesn't add up.
>
> if you have 18 million KiB and each file is a single block (512 Bytes =
> 0.5 Kib) then assuming zero overhead you could fit 18 Million KiB / 0.5
> KiB = 36 Million files on the drive.
>
> thus being scheptical about 40 million files on a 18G drive.
>
> this is only possible if you are abel to have multiple files per 512
> byte block.
I believe Reiser4 does this. Does ext3? I know I heard somewhere in
this thread that you can't set the blocksize lower than 1k...
David Masover
> 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
Hah! No, it doesn't sound exciting.
Plugins don't work well either, not as a marketing concept. People have
had so many bad experiences with plugins, and they're only ever visible
when you have a bad experience. Think about it -- missing plugin (so
you have to download it),
On the other hand, it works for WordPress. My day job is work on a
plugin for WordPress. Not including a link because I feel dirty for
having to work with PHP...
Fluid programming? If you build a solution from the bottom up with
gravel or large rocks, you leave gaps that are hard to fill without
ripping off the top layer and redoing it. But if you can do fluid
programming, your program just flows around any obstacle, and into every
crack / between every space (metaphor for new customer requirements)...
Luigi Genoni
On Wed, July 26, 2006 02:44, David Masover wrote:
> Hans Reiser wrote:
>
>
>> 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
>
> Hah! No, it doesn't sound exciting.
>
>
> Plugins don't work well either, not as a marketing concept. People have
> had so many bad experiences with plugins, and they're only ever visible when
> you have a bad experience. Think about it -- missing plugin (so you have to
> download it),
>
marketing?
</joke mode on>
if you do not like the word "plugin" why don't you suggest some alternative?
like "modules"?
</joke mode off>
Seriously, please leave out this kind of marketing. The plugin concept in
reiser4 is probably the most interessant feature I filesystem some users
could need.
>
> Fluid programming? If you build a solution from the bottom up with
> gravel or large rocks, you leave gaps that are hard to fill without ripping
> off the top layer and redoing it. But if you can do fluid programming, your
> program just flows around any obstacle, and into every crack / between every
> space (metaphor for new customer requirements)...
probably I do not know english enought well to appraciate this metaphor and
to understand what it means.
David Weinehall
> 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
> 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.
Well, the problem is that someone actually went through the
effort of doing the week-long reviews of your code, you flamed him
every time he suggested that there was need for improvement, instead
of saying thanks for all the hard work and implementing the needed
fixes.
Not exactly the right way to make people fond of reviewing your code.
Getting flamed by someone having a hard time taking criticism
after spending 5 minutes to review a patch is bearable, after all,
what's 5 minutes, right? Flaming someone that has put down a week
or two of hard work on review is just disrespectful.
[snip]
Regards: David Weinehall
--
/) David Weinehall <t...@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
Matthias Andree
> Matthias Andree wrote:
> > On Tue, 25 Jul 2006, Denis Vlasenko wrote:
> >
> >> I, on the contrary, want software to impose as few limits on me
> >> as possible.
> >
> > As long as it's choosing some limit, I'll pick the one with fewer
> > surprises.
>
> Running out of inodes would be pretty surprising for me.
No offense: Then it was a surprise for you because you closed your eyes
and didn't look at df -i or didn't have monitors in place.
There is no way to ask how many files with particular hash values you
can still stuff into a reiserfs 3.X. There, you're running into a brick
wall that only your forehead will "see" when you touch it.
Of course, different sites have different needs and if you need
gazillions of inodes or file names, you may see trouble.
But the assertion that some backup was the cause for inode exhaustion on
ext? is not very plausible since hard links do not take up inodes,
symlinks are not backups and everything else requires disk blocks. So,
since reformatting ext2/ext3 to one inode per block is possible
(regardless of disk capacity), I see no way how a reformatted file
system might run out of inodes before it runs out of blocks.
Matthias Andree
> But the assertion that some backup was the cause for inode exhaustion on
> ext? is not very plausible since hard links do not take up inodes,
> symlinks are not backups and everything else requires disk blocks. So,
> since reformatting ext2/ext3 to one inode per block is possible
> (regardless of disk capacity), I see no way how a reformatted file
> system might run out of inodes before it runs out of blocks.
OK; ext2/ext3 require 1k blocks, but still you need heaps of files < 1k
to run out of inodes without running of space.
Adrian Bunk
> Wow, I would never have guessed our market share was that high as 1/5th
> of ext3. I mean, you can't even get a distro which allows you to
> install onto reiser4 without hours of work so far as I know. I guess
> there are people who really do care about twice as fast.
I doubt Andreas values have much value.
According to the numbers on the klive website, Gentoo has 47 times as
many users as SuSE (sic).
Considering that klive is offered by someone working for SuSE, the
Gentoo project could make a good news article ("Numbers by a SuSE
developer confirm Gentoo has 47 times the market share of Suse.")
out of it. ;-)
> 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
Bernd Eckenfels
I know thats not relevant for the discussion, but I wanted to share my
experiences anyway (to emphasis how important df-i monitoring on smaller
filesystems is):
Matthias Andree <matthia...@gmx.de> wrote:
> But the assertion that some backup was the cause for inode exhaustion on
> ext? is not very plausible since hard links do not take up inodes,
> symlinks are not backups and everything else requires disk blocks. So,
> since reformatting ext2/ext3 to one inode per block is possible
> (regardless of disk capacity), I see no way how a reformatted file
> system might run out of inodes before it runs out of blocks.
Well I had actually the problem on a tmpfs where I had too many zero byte
files...
Gruss
Bernd
and...@cpushare.com
> On Tue, Jul 25, 2006 at 11:47:29AM -0600, Hans Reiser wrote:
>
> > Wow, I would never have guessed our market share was that high as 1/5th
> > of ext3. I mean, you can't even get a distro which allows you to
> > install onto reiser4 without hours of work so far as I know. I guess
> > there are people who really do care about twice as fast.
>
> I doubt Andreas values have much value.
I think nobody ever pretended them to have much value, they only need
to have some minor value to be useful. And as far as I can tell no
better source of data about the kernel testing userbase exists as of
today.
> According to the numbers on the klive website, Gentoo has 47 times as
> many users as SuSE (sic).
>
> Considering that klive is offered by someone working for SuSE, the
> Gentoo project could make a good news article ("Numbers by a SuSE
> developer confirm Gentoo has 47 times the market share of Suse.")
> out of it. ;-)
Oh well, you misunderstood KLive completely. Please read again the top
of the page: "this project aims to provide kernel live feedback about
the usage of every different Linux Kernel version". Where did I ever
mention anything about distributions?
There's absolutely no way to tell which distribution is running. I
only can tell which _kernel_ is running. It could be 100% of the
mainline users are running mainline on top of SUSE distro, or on top
of Gentoo, or on top of Ubuntuu, there's absolutely no way to know
about the distro. Nobody could ever make a claim like the above by
using the KLive data.
To make an example I run mainline myself on top of opensuse 10.1, and
I get rightfully accounted as a "mainline" and not as a "SUSE".
All you can tell is that there are many more people running KLive in
combination with Gentoo kernels than with SUSE kernels. But you can't
tell anything about what kind of distribution is running. One could
guess the Gentoo kernels run on top of a Gentoo userland, but for the
mainline ones you really can't tell, they could be slackware but they
could be any other distro too.
Also note that the cpushare.com domain is not related to any distro,
so the fact I also do consulting for SUSE is irrelevant to KLive or
any other dealings at the cpushare.com domain. As long there is people
running KLive and browsing the website like now, it means somebody
thinks it's useful and so I keep delivering the service.
As of now, the Gentoo and mainline kernel users are the ones providing
most of the feedback.
Perhaps I should have filed a patent on KLive too just to make you
happy, right?
Adrian Bunk
> On Wed, Jul 26, 2006 at 02:45:57PM +0200, Adrian Bunk wrote:
> > On Tue, Jul 25, 2006 at 11:47:29AM -0600, Hans Reiser wrote:
> >
> > > Wow, I would never have guessed our market share was that high as 1/5th
> > > of ext3. I mean, you can't even get a distro which allows you to
> > > install onto reiser4 without hours of work so far as I know. I guess
> > > there are people who really do care about twice as fast.
> >
> > I doubt Andreas values have much value.
>
> I think nobody ever pretended them to have much value, they only need
> to have some minor value to be useful. And as far as I can tell no
> better source of data about the kernel testing userbase exists as of
> today.
Hans said "Wow, I would never have guessed our market share was that
high as 1/5th of ext3."
And estimate of the marked share based on klive data is simply wrong.
That was my point.
My distribution example was just one example of what happens when you
wrongly try to estimate a marked share based on klive data (and it seems
you missed the smiley after the last paragraph of my email).
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
-
and...@cpushare.com
> My distribution example was just one example of what happens when you
> wrongly try to estimate a marked share based on klive data (and it seems
You're again wrong generalizing. With KLive I can attempt to estimate
market share of _kernel_ code (what Hans did), but you can't attempt
to estimate market share of userland (what you did). It won't be a
smile at the end making your statement right.
The estimate market share of kernel code may not be accurate but it
has some minor significance.
Adrian Bunk
> On Wed, Jul 26, 2006 at 03:43:26PM +0200, Adrian Bunk wrote:
> > My distribution example was just one example of what happens when you
> > wrongly try to estimate a marked share based on klive data (and it seems
>
> You're again wrong generalizing. With KLive I can attempt to estimate
> market share of _kernel_ code (what Hans did), but you can't attempt
> to estimate market share of userland (what you did). It won't be a
> smile at the end making your statement right.
No, you can't estimate the market share of kernel code based on klive
data.
Someone said in this thread 'is used by (tens of) thousands of computers
in governmental laboratories the US "national security" depends upon.'
klive will never get any feedback from such users.
But the computer freak using Gentoo and always trying the latest things
like reiser4 is relatively likely to also use klive.
> The estimate market share of kernel code may not be accurate but it
> has some minor significance.
You are able to say that based on klive data, reiser4 has at least
35 users in the world.
But you can not tell based on klive data whether the ratio of
reiser4:ext3 users in the world is more like 1:5, 1:500 or 1:50000.
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
-
Hans Reiser
>
>
>Although I should mention, Hans, that there is a really good reason to
>prefer the 15 minute patches. The patches that take a week are much
>harder to read during that week than any number of 15 minute incremental
>patches, because the incremental patches are already broken down into
>nice, small, readable, ordered chunks. And since development follows
>some sort of logical, orderly pattern, it can be much easier to read it
>that way than to try to consider the whole.
>
>
No, I disagree, if the code is well commented, it is easier to read the
whole thing at the end when it has its greatest coherence and
refinement. A problem with Reiser4 is that its core algorithms are
simply complex. We pushed the envelope in multiple areas all at once.
Benchmarks don't always suggest simple algorithms are the ones that will
be highest performance. Tree algorithms are notorious in the database
industry for being simple on web pages but complex as code.
Some people program in small increments, some program things that
require big increments of change, both kinds of people are needed.
Hans Reiser
>Hans Reiser wrote:
>
>
>
>>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".
>>
This phrase was a bit tongue-in-cheek.
>> Does that sound exciting to
>>
>>
>
>
>
-
and...@cpushare.com
> Someone said in this thread 'is used by (tens of) thousands of computers
> in governmental laboratories the US "national security" depends upon.'
There can be people using reiser4 behind the firewall too, what's the
point? IIRC US .gov even sponsored part of reiser4 development, how do
you know they're not testing it too?
You don't believe KLive has any relation to reality, but you have no
way to proof your claim. JFYI: all statistics only take a sample of
the larger space, the whole point of having a statistic is because you
can't measure the total. The smaller the sample compared to the total,
the less the stats are accurate, but they still have some statistical
significance. And one can always hope that KLive will grow larger.
Last but not the least defining gentoo users as freaks isn't very nice
from your part. For all new startups they're the ideal userbase to
have, and they do a great deal of good work by testing all new stuff
and they help speeding up innovation. Infact I think having a sample
of what those brave users run is more important than the rest, the
rest usually follows the ones living on the edge eventually.
Adrian Bunk
> On Wed, Jul 26, 2006 at 04:50:19PM +0200, Adrian Bunk wrote:
> > Someone said in this thread 'is used by (tens of) thousands of computers
> > in governmental laboratories the US "national security" depends upon.'
>
> There can be people using reiser4 behind the firewall too, what's the
> point? IIRC US .gov even sponsored part of reiser4 development, how do
> you know they're not testing it too?
I don't know.
The klive data might be inaccurate in any direction.
In this case I'd suspect an inaccuraty in one specific direction.
> You don't believe KLive has any relation to reality, but you have no
> way to proof your claim. JFYI: all statistics only take a sample of
> the larger space, the whole point of having a statistic is because you
> can't measure the total. The smaller the sample compared to the total,
> the less the stats are accurate, but they still have some statistical
> significance. And one can always hope that KLive will grow larger.
Size isn't everything.
The problem is getting an accurate sample of data.
Let me try to make the problem clearer by making an example:
Consider you want to know the ratio between housewifes and women with a
job for women aged between 30 and 40.
Consider you get your data by asking women in shopping malls between
10 and 11 o'clock in the morning on workdays.
Do you understand why the result might be quite different from the
actual ratio?
Do you understand why asking a million women in shopping malls between
10 and 11 o'clock in the morning on workdays wouldn't make the data
better?
And do you know the Linux Counter at [1]?
I remember several years ago Debian had some default setting in
some package to send reports there.
smail was at that times the default Debian MTA, and therefore also the
most popular MTA at the Linux counter...
> Last but not the least defining gentoo users as freaks isn't very nice
> from your part. For all new startups they're the ideal userbase to
> have, and they do a great deal of good work by testing all new stuff
Please read carefully what I said.
I did NOT say:
"All Gentoo users are freaks."
It was more (implicitely) in the direction:
"Many freaks use Gentoo."
The latter is IMHO not that far from reality.
And "freak" wasn't meant negative.
> and they help speeding up innovation. Infact I think having a sample
> of what those brave users run is more important than the rest, the
> rest usually follows the ones living on the edge eventually.
The majority of user will use the filesystem their distribution offers
as default, no matter what people living on the edge today will use...
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
-
J. Bruce Fields
> point of having a statistic is because you can't measure the total.
> The smaller the sample compared to the total, the less the stats are
> accurate
Definitely not true in general. If I wanted to know the gender ratio at
the latest OLS I'd take the results from a sample of a dozen chosen
randomly over the results from a sample of hundreds all taken from the
men's room.
For exactly the same quality of sampling, yes, the larger the better,
but the point of diminishing returns comes pretty quickly. So given
limited resources it's probably more important to work on the quality of
the sample rather than on its size....
--b.
and...@cpushare.com
> On Wed, Jul 26, 2006 at 06:06:04PM +0200, and...@cpushare.com wrote:
> > JFYI: all statistics only take a sample of the larger space, the whole
> > point of having a statistic is because you can't measure the total.
> > The smaller the sample compared to the total, the less the stats are
> > accurate
>
> Definitely not true in general. If I wanted to know the gender ratio at
> the latest OLS I'd take the results from a sample of a dozen chosen
> randomly over the results from a sample of hundreds all taken from the
> men's room.
Well, your example is perhaps the worst one since you wouldn't be
decreasing the quality of your stats very much by only doing the
sample in the men's room ;). I guess you meant the woman's room.
> For exactly the same quality of sampling, yes, the larger the better,
> but the point of diminishing returns comes pretty quickly. So given
> limited resources it's probably more important to work on the quality of
> the sample rather than on its size....
No matter how you see it, the larger the better (in the worst case it
won't make a difference). Certainly if I could work on the quality,
that would be more important than adding 1 more user. But I can't work
on the quality.
Russell Cattelan
> David Masover wrote:
>
> >
> >
> >Although I should mention, Hans, that there is a really good reason to
> >prefer the 15 minute patches. The patches that take a week are much
> >harder to read during that week than any number of 15 minute incremental
> >patches, because the incremental patches are already broken down into
> >nice, small, readable, ordered chunks. And since development follows
> >some sort of logical, orderly pattern, it can be much easier to read it
> >that way than to try to consider the whole.
> >
> >
> No, I disagree, if the code is well commented, it is easier to read the
> whole thing at the end when it has its greatest coherence and
> refinement. A problem with Reiser4 is that its core algorithms are
> simply complex. We pushed the envelope in multiple areas all at once.
> Benchmarks don't always suggest simple algorithms are the ones that will
> be highest performance. Tree algorithms are notorious in the database
> industry for being simple on web pages but complex as code.
>
> Some people program in small increments, some program things that
> require big increments of change, both kinds of people are needed.
>
Personally I find it difficult to completely stop what I'm doing
and spend several days studying a large patch/complete new subsystem.
But on the other hand it's important that code that goes in the kernel
gets a proper review, I think we all come to rely on the gatekeepers job
of making sure any given part of the kernel does not destabilize to the
point were it interferes with our individual areas of development.
So exactly what level of granularity is appropriate for changes? Well
that should probably be left of to the gatekeeper for each particular
area. In the case of filesystems generic vfs changes obviously need to
be small and easy to digest, and more importantly easy to bisect
regressions. The core of the file system can be left to the person who
can best manage the code, but hopefully that person applies a reasonable
of granularity to the changes, thus allowing non familiar developers to
at least keep up and possibly make helpful suggestions.
If we look at the current "beliefs" surrounding XFS you can see the
affects of a code base that did not have an incremental development with
regards to linux anyways. Ok so ya XFS was a close sourced IRIX FS for
the first 8 years of it's life, and even once the Linux project started
there was another year or so encumbrance investigation and cleaning
before legal would sign off on its release.
So to this day the major hang up with XFS seems to be "it's to complex
because it has x thousands lines of code". Hell by that argument Linux
has way more lines of code than IRIX could ever hope to have and is
therefore Linux is more complex than IRIX and to hard to understand. :-)
Fortunately many developers (especially ones that have worked on other
OS's) do not use "wc -l" as a tool to measure code
quality/readability/complexity.
XFS unfortunately will probably always suffer from skepticism since
it did not grow up in in Linux.
Guess it's sort of like adopting a 8 year old child vs a new born, hard
to tell what happened in first 8 years.
-Russell Cattelan
catt...@xfs.org
Buddy Lucas
>
> Matthias Andree <matthia...@gmx.de> wrote:
> > But the assertion that some backup was the cause for inode exhaustion on
> > ext? is not very plausible since hard links do not take up inodes,
> > symlinks are not backups and everything else requires disk blocks. So,
> > since reformatting ext2/ext3 to one inode per block is possible
> > (regardless of disk capacity), I see no way how a reformatted file
> > system might run out of inodes before it runs out of blocks.
>
> Well I had actually the problem on a tmpfs where I had too many zero byte
> files...
Yes, I once ran out of inodes because logrotate kept rotating and
compressing already compressed and empty logfiles. I can't remember
how many seconds it took me to add 'df -i' to our monitoring system.
This, however, was not a feature of the software. I assume.
So, any company that considers the remote possibility of seeking a
$250,000 solution, where the alternative is to buy a 36GB hard drive,
please give me a call.
Cheers,
Buddy
Jerome Pinot
> On Wed, Jul 26, 2006 at 01:02:36PM -0400, J. Bruce Fields wrote:
> > On Wed, Jul 26, 2006 at 06:06:04PM +0200, and...@cpushare.com wrote:
> > > JFYI: all statistics only take a sample of the larger space, the whole
> > > point of having a statistic is because you can't measure the total.
> > > The smaller the sample compared to the total, the less the stats are
> > > accurate
> >
> > Definitely not true in general. If I wanted to know the gender ratio at
> > the latest OLS I'd take the results from a sample of a dozen chosen
> > randomly over the results from a sample of hundreds all taken from the
> > men's room.
>
> Well, your example is perhaps the worst one since you wouldn't be
> decreasing the quality of your stats very much by only doing the
> sample in the men's room ;). I guess you meant the woman's room.
>
> > For exactly the same quality of sampling, yes, the larger the better,
> > but the point of diminishing returns comes pretty quickly. So given
> > limited resources it's probably more important to work on the quality of
> > the sample rather than on its size....
>
> No matter how you see it, the larger the better (in the worst case it
> won't make a difference). Certainly if I could work on the quality,
> that would be more important than adding 1 more user. But I can't work
> on the quality.
Maybe you could try pushing the use of klive by some distros arguing
it's "a way of getting usage statistics in order to improve kernel
quality and hardware support". I mean, not just an extra package but a
service launch at the first boot so anyone can use it.
klive is a nice project, it just needs more _different_ users and
maybe, a support of some distros.
Maybe, you could try add a page in the klive wiki for putting packages
and RPMs of klive for several distros ? What do you think ? It's a
first step to get it merge into distros.
In my case, I got some .tgz that feel lonely...
Maybe be in 2 years, we will know EXACTLY of much people use
EXT4/Reiser5/CoincoinFS/CrashFS...
--
Jerome Pinot
http://ngc891.blogdns.net/
and...@cpushare.com
doubt they're interested.
On Thu, Jul 27, 2006 at 04:01:02AM +0900, Jerome Pinot wrote:
> Maybe you could try pushing the use of klive by some distros arguing
> it's "a way of getting usage statistics in order to improve kernel
> quality and hardware support". I mean, not just an extra package but a
> service launch at the first boot so anyone can use it.
>
> klive is a nice project, it just needs more _different_ users and
> maybe, a support of some distros.
That would be nice yes. KLive is already supported by Gentoo that
created a proper emerge package, that's why there are so many gentoo
kernels being tracked. Others are of course welcome. I'm open to
suggestions on extending it as well.
At the moment the todo list is like this:
1) create an optional http transport to pass through most firewalls
2) send a packet when system reboots so I can track which sessions
didn't cleanly reboot (it's not reliable if you disconnect
from the internet first and you shutdown later, but it's better
than nothing)
3) send the oops from kernel to klive server, so no oopses will be
lost and I can use the pciids details to track down bad hardware
as well
4) possibly send info on usb buses too and not only about the pci buses
> Maybe, you could try add a page in the klive wiki for putting packages
> and RPMs of klive for several distros ? What do you think ? It's a
> first step to get it merge into distros.
If more distros will pickup KLive that will help like demonstrated by
the emerge package from gentoo.
It's already very simple to install klive, I wrote an universal
installer that runs on any flavour of any weird distro out there:
wget klive.cpushare.com/klive.sh
sh klive.sh --install
If you don't want it anymore:
sh klive.sh --uninstall
that's it.
The rpm/deb packages would be just to make life easier for distro to
pick it up but I hoped they had the resources to do the packaging work
themself...
Perhaps once I'll create the CPUShare rpm/deb packages I'll be easy to
share the work to create the KLive ones too. As far as spare time work
goes, CPUShare currently has a much higher prio than KLive, and I'm
not yet at the point of creating rpm/deb packages, now that CPUShare
transaction works and you can already compute remotely, I'm currently
fighting with the paypal sendbox so I can start accepting cash into
the system ASAP. But the hardest part of the ebusiness side of
CPUShare is the handling of the invoicing and receipts generation
which is a non computer related problem. I almost solved it though.
> In my case, I got some .tgz that feel lonely...
The .tgz is only for the ones interested hacking or studying it (both
client and server). You should be using the .sh script above.
Also note, the export of the whole database isn't available on the
site, but I've no problem to publish it after filtering out all the ip
addresses (which are collected only for purely paranoid security
purposes, and tor doesn't route udp traffic).
> Maybe be in 2 years, we will know EXACTLY of much people use
> EXT4/Reiser5/CoincoinFS/CrashFS...
BTW, CPUShare records a lot more than the fs already. 2 years or more,
but I'm not in a hurry. The server will also soon require some caching
trick to avoid recomputing the queries every time you click on
it. Current KLive is the best I could do in a very little time I spent
on it, it works well, but it still has an huge room for
improvement. Also note, so far KLive logged 76989 cumulative days of
uptime. When I see a number like that my mind thinks at the energy
that can be recycled if all that time recorded on KLive would be
routed inside CPUShare. That's why for me it's more urgent to give a
chance to those brave 500 users to cash in with CPUShare than to push
KLive beyond its current status ;). In due time KLive will get more
attention too.
Adrian Bunk
> On Wed, Jul 26, 2006 at 01:02:36PM -0400, J. Bruce Fields wrote:
> > For exactly the same quality of sampling, yes, the larger the better,
> > but the point of diminishing returns comes pretty quickly. So given
> > limited resources it's probably more important to work on the quality of
> > the sample rather than on its size....
>
> No matter how you see it, the larger the better (in the worst case it
> won't make a difference). Certainly if I could work on the quality,
> that would be more important than adding 1 more user. But I can't work
> on the quality.
But depending on the nature of the error, the worst case might be the
common case (as I've already explained in another email).
If you can't ensure the quality of your data, please don't use this data
to wrongly draw any conclusions from them [1].
cu
Adrian
[1] the conclusion itself might or might not be true
e.g. there _could_ be an 1:5 ratio between reiser4 and ext3 users
but your data is not in any way able to support or reject this
statement
--
"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
-
and...@cpushare.com
> But depending on the nature of the error, the worst case might be the
> common case (as I've already explained in another email).
>
> If you can't ensure the quality of your data, please don't use this data
> to wrongly draw any conclusions from them [1].
Please read the footer of the KLive pages:
"The use of the information and of the software in this website is at
your own risk. KLive probably doesn't represent a reliable sample of
the real usage of the Linux Kernel."
Said that pretending that KLive data has absolutely no significance at
all and that you can't draw any conclusion at all from it, to me seems
as wrong as pretending it to perfect.
J. Bruce Fields
> Said that pretending that KLive data has absolutely no significance at
> all and that you can't draw any conclusion at all from it, to me seems
> as wrong as pretending it to perfect.
This is where we disagree. It may be wrong, but it's certainly not
nearly *as* wrong....
--b.
and...@cpushare.com
> This is where we disagree. It may be wrong, but it's certainly not
> nearly *as* wrong....
;)
My point of view in saying you can't dismiss the current KLive stats
completely, is simply that I didn't expect reiser4 numbers to be so
high even in the small sample of the brave KLive project that is full
of people willing to test new stuff (also note that I compared it to
isofs, I didn't attempt a comparison with ext3 myself). That makes it
a positive in my view.
If you think KLive numbers aren't a positive point for reiser4, then
it can only mean you expected them to be even higher than they were...
David Masover
> Guess it's sort of like adopting a 8 year old child vs a new born, hard
> to tell what happened in first 8 years.
And, by that token, the newborn is sometimes preferable. It hasn't had
time to develop severe emotional problems, it's physically harmless, and
you get to help it form its ideas and beliefs.
On the other hand, the 8 year old is potty trained, you won't have to
change a single diaper, it's intelligent and makes you question things,
it understands what you want it to do...
So, it depends what kind of developer you are, what kind of gatekeeper,
and what kind of project it is. I still believe in releasing early and
often, but I can see many reasons not to. Some are financial -- Namesys
is trying to operate a business, so any features they open up too early
could be that much harder to sell as a commercial product. The
repacker, for instance.
I'm not arguing for closed source, I'm just saying that once you open,
there's no going back. Many times it's a good thing, but sometimes you
want to wait and see.
David Masover
> On Tue, 25 Jul 2006, David Masover wrote:
>
>> Matthias Andree wrote:
>>> On Tue, 25 Jul 2006, Denis Vlasenko wrote:
>>>
>>>> I, on the contrary, want software to impose as few limits on me
>>>> as possible.
>>> As long as it's choosing some limit, I'll pick the one with fewer
>>> surprises.
>> Running out of inodes would be pretty surprising for me.
>
> No offense: Then it was a surprise for you because you closed your eyes
> and didn't look at df -i or didn't have monitors in place.
Or because my (hypothetical) business exploded before I had the chance.
After all, you could make the same argument about bandwidth, until you
get Slashdotted. Surprise!
> There is no way to ask how many files with particular hash values you
> can still stuff into a reiserfs 3.X. There, you're running into a brick
> wall that only your forehead will "see" when you touch it.
That's true, so you may be correct about "less" surprises. So, it
depends which is more valuable -- fewer surprises, or fewer limits?
That's not a hypothetical statement, and I don't really know. I can see
both sides of this one. But I do hope that once Reiser4 is stable
enough for you, it will be predictable enough.
> But the assertion that some backup was the cause for inode exhaustion on
> ext? is not very plausible since hard links do not take up inodes,
> symlinks are not backups and everything else requires disk blocks. So,
Ok, where's the assertion that symlinks are not backups? Or not used in
backup software? What about directories full of hardlinks -- the dirs
themselves must use something, right?
Anyway, it wasn't my project that hit this limit.
Hans Reiser
>[1] the conclusion itself might or might not be true
> e.g. there _could_ be an 1:5 ratio between reiser4 and ext3 users
> but your data is not in any way able to support or reject this
> statement
>
>
It does however suggest that my surprise at how people at the last
Linux Conference I went to all seemed to know that there exists a
Reiser4 may be due to it being more widely used than I would have
guessed. Maybe there is some coolness factor to having the faster FS
that you can't get from any Distro that is enough to overcome the hassle
of compiling reiser4progs and a kernel before inserting the DVD. I
would not have guessed we had 1/5th of ext3's usage even among lkml
readers..... I guess the market contains more people who like
technology than I was guessing. Maybe there is a positive word of mouth
effect going on too.
It would be nice if SuSE and others at least made it an unsupported
option at install time. I shall have to find the time to go asking them
all.....
Hans
Adrian Bunk
> > But depending on the nature of the error, the worst case might be the
> > common case (as I've already explained in another email).
> >
> > If you can't ensure the quality of your data, please don't use this data
> > to wrongly draw any conclusions from them [1].
>
> Please read the footer of the KLive pages:
>
> "The use of the information and of the software in this website is at
> your own risk. KLive probably doesn't represent a reliable sample of
> the real usage of the Linux Kernel."
It was you who wrongly said:
"With KLive I can attempt to estimate market share of _kernel_ code"
Hadn't you read your own disclaimer?
> Said that pretending that KLive data has absolutely no significance at
> all and that you can't draw any conclusion at all from it, to me seems
> as wrong as pretending it to perfect.
Possibly wrong conclusions about the general market share based on data
not having the quality for being the basis of such statements are worse
than having no data.
Every time someone will repeat the "1:5 ratio for reiser4:ext3 users",
this will be an additional proof it's really worse than no data.
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
-
Luigi Genoni
On Thu, July 27, 2006 08:56, Adrian Bunk wrote:
>
>> Said that pretending that KLive data has absolutely no significance at
>> all and that you can't draw any conclusion at all from it, to me seems as
>> wrong as pretending it to perfect.
>
> Possibly wrong conclusions about the general market share based on data
> not having the quality for being the basis of such statements are worse than
> having no data.
Am I missing something, or it is not marketing what we are talking about?
please I do not understand your point.
For what I understand... I was not supposing reiser4 users to be so mutch,
but this is very usefull because this means that there are more
possibilities to test the code well and to fix bugs...
This also means that there are people who feels the need of this filesystem
for their work because they are not satisfied with the other filesystems, or
because anyway with reiser4 they see that they get better results about the
work they need to be done.
And this is probably the most important point.
Adrian Bunk
>
>
>
> On Thu, July 27, 2006 08:56, Adrian Bunk wrote:
> >
> >> Said that pretending that KLive data has absolutely no significance at
> >> all and that you can't draw any conclusion at all from it, to me seems as
> >> wrong as pretending it to perfect.
> >
> > Possibly wrong conclusions about the general market share based on data
> > not having the quality for being the basis of such statements are worse than
> > having no data.
>
> Am I missing something, or it is not marketing what we are talking about?
> please I do not understand your point.
>
> For what I understand... I was not supposing reiser4 users to be so mutch,
> but this is very usefull because this means that there are more
> possibilities to test the code well and to fix bugs...
I'm sorry for saying it that directly, and this is not meant against you
personally:
Your statement is a good example why this data is worse than having no
data.
As I already said in this thread:
<-- snip -->
You are able to say that based on klive data, reiser4 has at least
35 users in the world.
But you can not tell based on klive data whether the ratio of
reiser4:ext3 users in the world is more like 1:5, 1:500 or 1:50000.
<-- snip -->
I can't prove that the 1:5 ratio is wrong, but the point is that
claiming a 1:5 ratio was true based on the klive data is not better than
claiming it based on no data. But claiming it based on the klive data is
worse since people like you are getting the wrong impression it was
based on data that would have the quality for supporting such a
statement.
The data simply has not the quality for such a statement.
Please read my two examples in [1] if you want to get an impression why
such problems can occur.
cu
Adrian
[1] http://lkml.org/lkml/2006/7/26/203
--
"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
-
Luigi Genoni
I am not interested in discussing about 1:5 ora 5:1 or so on.
I am not even interested if reiser4 users are 35 or 35000.
But if some people felt they need reiser4 to get their work done, that means
something. The numbers and the datum per se are meaningless.
Anyway you have a datum.
Some people need reiser4, period.
Why they need reiser4?
all of them are just playing with him to have a new game for their spare time?
I don't think so.
Some of them are using reiser4 because it is the best solution for their work?
this is a concrete possibility.
again... why that?
Because the other FSs are not suitable for certain work?
Because the other FSs are suitable, but reiser4 offers better results?
Because even reiser4 is not complitelly suitable for some kind of work, but
the other FSs are a worser solution?
I don't think most reiser4 users decided to give it a try just to enjoy
their time making tests just because they are curious.
that does not mean reiser4 should be merged into linux kernel because of
this. On the other side you can agree reiser4 has its place, because there
are users who need it. What we would need to understand, sine ira nec
studio, is where this place is.
Adrian Bunk
> Still I am missing something.
>
> I am not interested in discussing about 1:5 ora 5:1 or so on.
> I am not even interested if reiser4 users are 35 or 35000.
> But if some people felt they need reiser4 to get their work done, that means
> something. The numbers and the datum per se are meaningless.
>...
You answered to an email where I talked about the wrong assumption the
klive data could support the 1:5 market share claim.
This is completely independent from discussions about why users might
need reiser4, or which technical or social problems prevent its merging
(unless of course someone wants to justify its merging wrongly with the
1:5 claim), and therefore your answer does not apply to this part of
the thread.
cu
Adrian
Luigi Genoni
could even be dangerous...
and...@cpushare.com
> On Wed, Jul 26, 2006 at 11:17:41PM +0200, and...@cpushare.com wrote:
> > On Wed, Jul 26, 2006 at 10:50:22PM +0200, Adrian Bunk wrote:
> > > But depending on the nature of the error, the worst case might be the
> > > common case (as I've already explained in another email).
> > >
> > > If you can't ensure the quality of your data, please don't use this data
> > > to wrongly draw any conclusions from them [1].
> >
> > Please read the footer of the KLive pages:
> >
> > "The use of the information and of the software in this website is at
> > your own risk. KLive probably doesn't represent a reliable sample of
> > the real usage of the Linux Kernel."
>
> It was you who wrongly said:
> "With KLive I can attempt to estimate market share of _kernel_ code"
>
> Hadn't you read your own disclaimer?
There is no contradiction in the two statements. To attempt to
estimate something I don't need a reliable sample of the whole
population. Estimation is still a statistical thing. Also I said
attempt to estimate, it doesn't mean I will make it.
If you don't consider those results a positive for reiser4, it can
only mean you expected reiser4 to have a much higher share among the
KLive users. This is obvious.
> Every time someone will repeat the "1:5 ratio for reiser4:ext3 users",
> this will be an additional proof it's really worse than no data.
If they say "1:5 ratio for reiser4:ext3 KLive users" everything will
be correct and nobody can object because it's a fact.
I said myself that I'm no reiserfs user, and I don't plan to become
one any time soon (especially on my production systems), I'm only
reporting plain numbers as KLive measured the stuff. I'm surprised as
much as you are, but then I've to report facts, and not my own
opinions.
As far as I'm concerned the thing I like less of reiser4 is the plugin
thing, I'd be less concerned if that was a microkernel (fuse-like)
userland plugin system. Anyway with time perhaps things can change and
become userland based, and the stuff can be moved into vfs if that
code really belongs there as some kernel developer says. That doesn't
mean reiser4 can't be merged first and the stuff moved into vfs
later. xfs when was merged also pratically rewrote a vfs internally
that was meant to work with irix, if Christoph didn't complain about
xfs being merged, I don't see what's the problem of reiser4 being
merged even if it rewrites some part of vfs. xfs is also still having
various special features like the pinhole one that only belongs to the
vfs instead but nobody complains.
And if reiser4 is really so bad as they say, once people starts losing
data they will spread the word of not using it. As long as it's marked
experimental I don't see a big issue, the wireless driver for broadcom
chip will eat your filesystem too if the reverse engineered dma
operations writes into a buffer header instead of an skb.
Adrian Bunk
> I answered a mail about how klive data should not be took in account, and
> could even be dangerous...
... and you talking about people who might need reiser4 was therefore
a wrong answer.
I never said reiser4 shouldn't be merged, but this wasn't the topic of
this subthread.
Adrian Bunk
> On Thu, Jul 27, 2006 at 08:56:03AM +0200, Adrian Bunk wrote:
> > It was you who wrongly said:
> > "With KLive I can attempt to estimate market share of _kernel_ code"
> >
> > Hadn't you read your own disclaimer?
>
> There is no contradiction in the two statements. To attempt to
> estimate something I don't need a reliable sample of the whole
> population. Estimation is still a statistical thing. Also I said
Sure, you don't need any data to estimate anything.
But if your estimate is based on bad data it sounds better than if it
was based on no data although the value of the estimate is the same.
> attempt to estimate, it doesn't mean I will make it.
Giving low quality raw data and then saying "it wasn't me who did the
estimate" is silly.
> If you don't consider those results a positive for reiser4, it can
> only mean you expected reiser4 to have a much higher share among the
> KLive users. This is obvious.
That's completely wrong.
I consider those results neither positive nor negative for reiser4.
They could only be considered positive if someone expected less than
35 reiser4 users worldwide.
> > Every time someone will repeat the "1:5 ratio for reiser4:ext3 users",
> > this will be an additional proof it's really worse than no data.
>
> If they say "1:5 ratio for reiser4:ext3 KLive users" everything will
> be correct and nobody can object because it's a fact.
And 90% of all people will misread it.
And many people will spread it wrong.
That's exactly where such data is worse than no data.
You could claim you know your the suboptimal quality of the data and
that you had a disclaimer.
But did you read Hans' reaction on your email?
If you are intelligent (which I assume), you should have learned by this
how to not present your data.
> I said myself that I'm no reiserfs user, and I don't plan to become
> one any time soon (especially on my production systems), I'm only
> reporting plain numbers as KLive measured the stuff. I'm surprised as
> much as you are, but then I've to report facts, and not my own
> opinions.
>...
I have no plans to use reiser4 myself (I'm a happy ext2 user).
But I'm not against mergng reiser4, either.
I'll leave this technical discussion to the people who know more about
this.
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
-