Message-ID: <44C9FB93.9040201@namesys.com>
Date:	Fri, 28 Jul 2006 05:57:07 -0600
From:	Hans Reiser <reiser@...esys.com>
To:	Linus Torvalds <torvalds@...l.org>
CC:	David Masover <ninja@...phack.com>,
	"Horst H. von Brand" <vonbrand@....utfsm.cl>,
	Jeff Garzik <jeff@...zik.org>, Andrew Morton <akpm@...l.org>,
	Theodore Tso <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>,
	ReiserFS List <reiserfs-list@...esys.com>
Subject: Re: metadata plugins (was Re: the " 'official' point of view" expressed
 by kernelnewbies.org regarding reiser4 inclusion)

Linus Torvalds wrote:

>
>
>In other words, if a filesystem wants to do something fancy, it needs to 
>do so WITH THE VFS LAYER, not as some plugin architecture of its own.
>
Where does VFS store the plugin ids that specify per file variations? 
/etc/fstab?  Also, is (current) VFS the interface for specifying where
the hash directory plugin goes (specifies what order directory entries
are within the directory)?  What about the node layout plugin?  The disk
format plugin?  Etc.?  Our approach is different, but it has reasons.

We eliminated the layer of indirection that Hellwig objected to, in
which VFS called the plugin which called its method. 

(Let us try to avoid arguments over whether if you extend VFS it is
still called VFS or is called reiser4's plugin layer, agreed?)

Regarding copyright, these plugins are compiled in.  I have resisted
dynamically loaded plugins for now, for reasons I will not go into here.

You can either portray reiser4 as duplicating VFS, or you can portray it
as taking it to the next level, in which files (objects with classes and
methods) vary rather than solely filesystems.  I would prefer the latter.;-)

If you agree with taking it to the next level, then it is only to be
expected that there are things that aren't well suited as they are, like
parsing /etc/fstab when you have a trillion files.  It is not very
feasible to do it for all of the filesystems all at once given finite
resources, it needs a prototype. 

> We 
>already have exactly the plugin interface we need, and it literally _is_ 
>the VFS interfaces - you can plug in your own filesystems with 
>"register_filesystem()", which in turn indirectly allows you to plug in 
>your per-file and per-directory operations for things like lookup etc.
>
>If that isn't enough, then the filesystem shouldn't make its own internal 
>plug-in architecture that bypasses the VFS layer and exposes functionality 
>that isn't necessarily sane. For example, reiser4 used to have (perhaps 
>still does) these cool files that can be both directories and links, and I 
>don't mind that at all, but I _do_ mind the fact that when Al Viro (long 
>long ago) pointed out serious locking issues with them, those seemed to be 
>totally brushed away.
>  
>
We disabled them, and we won't enable them until them until the bug is
fixed.  It is fixable, but not within this year's programmer resources
to fix it.  I thank him for pointing out the bug, and it is not trivial
to fix it.

>I don't think I've ever had the cojones to argue with Al..
>  
>
Linux needs all kinds of people, not just the kind that can audit
locking and copy Plan 9 well (which was very valuable to do), but now
that Linux is large in the market it also needs those who can take it
where Plan 9 has not already been.   Why should we remain technology
trailers instead of moving into the role of leaders?

We have finite resources.  We can give you a working filesystem with
roughly twice the IO performance of the next fastest you have that does
not disturb other filesystems,.  (4x once the compression plugin is
fully debugged).  It also fixes various V3 bugs without disturbing that
code with deep fixes.  We cannot take every advantage reiser4 has and
port it to every other filesystem in the form of genericized code as a
prerequisite for going in, we just don't have the finances.  Without
plugins our per file compression plugins and encryption plugins cannot
work.  We can however let other filesystems use our code, and cooperate
as they extend it and genericize it for their needs.  Imposing code on
other development teams is not how one best leads in open source, one
sets an example and sees if others copy it.  That is what I propose to
do with our plugins.  If no one copies, then we have harmed no one. 
Reasonable?

Hans

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

Powered by blists - more mailing lists