lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: silent semantic changes with reiser4
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.027 / U:0.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site