[lkml]   [2004]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: silent semantic changes with reiser4

    Linus Torvalds wrote:

    > The same goes for something like a "container file". Whether you see it as
    > "dir-as-file" or "file-as-dir" (and I agree with Jan that the two are
    > totally equivalent), the point of having the capability in the kernel is
    > not that the operations cannot be done in user space - the point is that
    > they cannot be done in user space _safely_. The kernel is kind of the
    > thing that guarantees that everybody follows the rules.

    Well, it CAN be done safely if every client has to go through the kernel
    which does all the appropriate locks/semaphors and then passes the
    request down to the daemon. (Isn't NFS implemented this way?)

    This is very micro-kernel-ish, but it's a reasonable idea to do it this
    way in cases where things are non-critical.

    Say there's a way to cd into a tgz file to look around. If the access
    methods through the kernel get routed back to a user-space process
    (which probably does some amount of caching in memory and on disk of
    uncompressed bits of the archive), it could be a bit slower than if it
    were all in-kernel. The thing is that the processing time in the daemon
    is probably quite high compared to the overhead of the context switches,
    so it doesn't cost much. (And if it CAN be done in userspace without
    being horribly convoluted or unsafe, then it SHOULD be done in
    userspace.) Besides, even if it were a LOT slower to access a tgz file
    without extracting it first, I would STILL think it was wonderful AND
    use it a LOT.

    Heh... now, the next thing is to be able to do some sort of union-mount
    like thing where the tgz is really read-only but if you WRITE to it, it
    gets stored somewhere else. This way, you can compile a kernel tree
    without extracting it first.

    Taking this a bit further, the union-mount could be done away with if
    the daemon were to lazily rebuild the tgz file from its cache when the
    tgz is modified. That is, writes have little or no penalty because they
    just get stored in the daemon's cache, and the daemon rebuilds the
    archive in the background.

    The VFS layer would have to recognize that a particular file has been
    accessed in such a way that it must go through the daemon for ANY access
    to it, which means that if someone tries to access the original archive
    as a file, requests have to go through the daemon. This makes it
    coherent, although with an expected performance penalty.

    One issue to consider is that of shutdowns, both intentional and
    crashes. This is a non-issue with an underlying journaling file system.
    As long as the tgz daemon comes up early enough, it would see its
    cache (which is on-disk anyway), recognize which archive it belongs to,
    and continue where it left off. This way, the daemon doesn't have to go
    through a long process of rebuilding every archive you've ever modified
    on the disk on shut-down. If, however, you needed to access the archive
    without the daemon, that could be a problem (but what you'd get is
    probably the archive before it was modified). Also, some sort of sync
    command would be needed to cause the daemon to rebuild all archives

    I really dig the idea of being able to access archives without
    extracting them first, regardless of any performance penalty.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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