[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: silent semantic changes with reiser4
    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 the plugins. You can insert,
    remove, lookup or modify key:object pairs (with an index into the
    object). The object 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.

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:05    [W:0.021 / U:36.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site