Re: silent semantic changes with reiser4

[Hans Reiser]

Christophe Saout wrote:

> Am Donnerstag, den 26.08.2004, 01:45 -0700 schrieb Andrew Morton:
>
>  
>
> > And describe the "plugin" system.  Why does the filesystem need such a
> > thing (other filesystems get their features via `patch -p1')?
> >    
>
> Ok, let me try. (Hans, please don't shoot me if I don't get every detail
> right, I'm trying to simplify and translate)
>
> The reiser4 core is just a big and fast storage layer using a single
> tree. It is bound to a mount point and uses the page cache to manage its
> memory. The only thing it can do on its own is to flush dirty data to
> the disk when the VM wants to (memory pressure) or the VFS wants to
> (unmount, sync) or some "plugin" wants to.
> Additionally it's completely atomic (with respect to crashes, no
> isolation like in databases), comparable to data=journal but without the
> overhead of using a journal for everything.
>
> Up to this point there are no users of this "database" and it does not
> implement any of the VFS methods for a filesystem (except mount and
> unmount perhaps).
>
> All the functionality is provided to
^to^via
apologies for the correction but it might confuse some

> the plugins. You can insert,
> remove, lookup or modify key:object pairs (with an index into the
> object). The object
^object^item
perform that substitution everywhere in this email

> is a sequence of units. For files a unit would be 1
> byte and the index would be the byte offset. For directories the unit
> would be 1 entry and the index would be the filename.
>
> Now there are some plugins that define how the storage layout on the
> disk is (some kind of "backend" plugins).
>
> *And* there are plugins which are users of the "reiser4 client API" and
> implement the actual VFS methods.
>
> There's a UNIX directory plugin and a UNIX file plugin.
>
> Directories, inodes and file content are just key:object pairs and the
> plugins know how to operate on these.
>
> There's a new plugin in work that also implements UNIX file semantics
> but stores the data for that file encrypted and/or compressed.
>
> These plugins live between the VFS and the storage layer.
>
> Just like the filesystems live between the VFS and the block layer (Hans
> would say that filesystems are VFS plugins ;-)).
>
>  
>
> > And what are the licensing implications of plugins?  Are they derived
> > works?  Must they be GPL'ed?
> >    
>
> I suppose yes, at least currently, since they can only be linked with
> reiser4, there's no module infrastructure.
>
>  

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