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

    On Sun, 29 Aug 2004 wrote:
    > A slew of cache coherency issues (and memory consumption on top of that).
    > Rigth now we have a signle dentry tree for all fs instances, no matter
    > how many times it and its subtrees are visible in the tree. Which,
    > obviously, avoids all that crap. As soon as we start trying to have
    > multiple trees over the same fs, we are in for a *lot* of fun.

    Al, I think you should make the argument a bit more specific, because I
    doubt a lot of people understand just what the problems are with aliased
    names. Just a few examples of the problems involved will illuminate things
    very well, I think. People who haven't been intimate with the name caches
    probably simply don't understand why you worry so much.

    I'll start out with some trivial examples, just to let Hans and others get
    an idea about what the issues are. I think examples of problems are often
    better ways to explain them than the abstract issues themselves.

    Aliases: let's say that you have filename "a" hard-linked to filename "b",
    and you have a directory structure of streams under there. So you have


    and (through the hard-link with "b") you have aliases of all these same
    names available as "b/file1", "b/dir1/file2" etc).

    Now, imagine that you have two processes doing

    mv a/dir1 a/dir2/newdir


    mv b/dir2 b/dir1/newdir

    at the same time. Both of them MUST NOT SUCCEED, for pretty obvious
    reasons (you'd have moved two directories within each other, and now
    neither would be accessible any more).

    How do you handle locking for this situation?

    Another interesting case is what happens when you have looked up and cache
    the filename "a/file1" and then another process does "rm b/file1". How do
    you update the _other_ cached copy, since they had two different names,
    but _both_ names went away at the same time. Also again, how do you handle

    The general VFS layer has a lot of rules, and avoids these problems by
    simply never having aliases between two directories. If the same directory
    shows up multiple times (which can happen with bind mounts), they have the
    exact same dentry for the directory, it's just found through two different
    vfsmount instances. That's why vfsmounts exist - they allow the same name
    cache entry to show up in different places at the same time.

    So when we do a bind mount, and the same directory shows up under two
    different names "a" and "b", and we do a "rm b/file1", it _automatically_
    disappears from "a/file1" too, simply by virtue of "a" and "b" literally
    being the same dentry. No aliasing ever happens, and this makes coherency
    and locking much easier (which is not to say that they are trivial, but
    they are pretty damn clear in comparison to the alternatives).

    What Al (and others) worries about is that the reiser4 name handling has
    _none_ of these issues figured out and protected against. You can protect
    against them by taking very heavy locks (you can trivially protect against
    all races by taking one large lock around any operation), but the fact is,
    that is just not an option for high-performance name lookup.

    These aliasing/locking rules need to be global and wll-though-out. Not
    just fix the two examples above, but be shown to be safe _in_general_.

    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: 2009-11-18 23:46    [W:0.055 / U:3.248 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site