Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)

[Hans Reiser <reiser@namesys.com>]

Jeff Garzik wrote:

>
> Using guilt as an argument in a technical discussion is a flashing red
> sign that says "I have no technical rebuttal"

Wow, that is really nervy.  Let's recap this all:

* reiser4 has a 2x performance advantage over the next fastest FS
(ext3), and when compression ships in a month that will double again as
well as save space.  See http://www.namesys.com/benchmarks.html, and
then ask the reiserfs-list@namesys.com whether those benchmarks are fair
representations of their experiences.  This is  in a field where a 25%
advantage is a hard won big deal.

* we described our plugin architecture in 2001.  No other FS developers
were interested, only the users were, and it was presented quite a lot.

* So we implemented plugins for ourselves, because no other FS
developers would possibly have supported us touching their code.  (I do
not say that they erred in this.)

* No one has actually made a serious case for it being genericizable
when you get to the details, it is all just handwaving.  I'd be
surprised if >10% of it was FS independent, and unsurprised if making
that 10% FS independent made the code ossified and hard to maintain.  I
do not in anyway claim that those who choose to implement Reiser4
plugins are not deeply affected by Reiser4 design choices.  Most of the
value of writing Reiser4 plugins comes from being able to reuse Reiser4
code as you choose to in the process, and if Reiser4 is not to your
taste as a whole, then nobody should impose our plugins upon you.  VFS
is a bad enough straight jacket for FS developers, we don't need even
more mandated design decisions for the FS developers to come who will be
brighter than us.  Actually, I would like to see Nate Diller implement a
competing VFS layer, I think he would do a very good job of that.

* Here we are today, and Reiser4 plugins work.  Now some say that
because we did it for Reiser4 and not for every other FS, that we should
be excluded from the kernel.  So we are supposed to re-implement it as
generic code, which will involve years of time, and then finally
something will be coded and nobody but us will use it, and then they
will tell us that because nobody but us wants to use it it cannot go
in.  If you disagree, find one ext3 developer who wants to rewrite ext3
to use plugins and change its disk format to do it. 

And you have the nerve to say that this ever was a technical
discussion?   Our code measurably works the best.  If folks want to
imitate it, go ahead, but don't blame us for making our code work
without first making those other folks's code work.  

The technical rebuttal you ask for is
http://www.namesys.com/benchmarks.html.

The only time this argument gets technical is when akpm is involved.  He
was right about what should technically be done about batch write,
which, by the way, was greeted upon completion with an if only reiser4
uses it then it should not go in response. 

We are being penalized for thinking too differently, and this whole
ping-pong between "no we don't want to do it your way" and "you did it
your way for only you, redo it for us even though we won't ever use it"
and "oh, you redid it for us but none of us want to use it, so no it is
an imposition and cannot go in" is the Kafka-esque manifestation of that. 

If only reiser4 wants to use something, then just let us do it in our
little corner without bothering anybody else.   (Though any advice from
akpm that he has time for giving us is always welcome.)  David, we
aren't asking to be in the band, we are asking to be in the jukebox.   I
think enough users want to go 2x as fast that the users would benefit
from our being in the jukebox.

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