lkml.org 
[lkml]   [2007]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH] file as directory
    From
    Date
    > > > Interesting...  How do you deal with mount propagation and things like
    > > > mount --move?
    > >
    > > Moving (or doing other mount operations on) an ancestor shouldn't be a
    > > problem. Moving this mount itself is not allowed, and neither is
    > > doing bind or pivot_root. Maybe bind could be allowed...
    >
    > Eh... Arbitrary limitations are fun, aren't they?

    But these mounts _are_ special. There is really no point in moving or
    pivoting them.

    > > When doing recursive bind on ancestor, these mounts are skipped.
    >
    > What about clone copying your namespace?

    In that case they are cloned, but only those survive which have refs
    in the new namespace.

    > What about MNT_SLAVE stuff being set up prior to that lookup?

    These mounts are not propagated. Or at least I hope so. Propagation
    stuff is a bit too complicated for my poor little brain.

    > More interesting question: should independent lookups of that sucker
    > on different paths end up with the same superblock (and vfsmount for
    > each) or should we get fully independent mount on each? The latter
    > would be interesting wrt cache coherency...

    I think they should be the same superblock, same dentry. What would
    be the advantage of doing otherwise?

    > > > As for unlink... How do you deal with having that thing
    > > > mounted, mounting something _under_ it (so that vfsmount would be kept
    > > > busy) and then unlinking that sucker?
    > >
    > > Yeah, that's a good point. Current patch doesn't deal with that.
    > > Simplest solution could be to disallow submounting these. Don't think
    > > it makes much sense anyway.
    >
    > Arbitrary limitations... (and that's where revalidate horrors come in, BTW).
    > BTW^2: what if fs mounted that way will happen to have such node itself?

    I think doing this recursively should be allowed. "Releasing last ref
    cleans up the mess" should work in that case.

    > I'm not saying that it's unfeasible or won't lead to interesting things,
    > but it really needs semantics done right...

    Agreed :)

    Miklos
    -
    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: 2007-05-23 09:23    [W:3.568 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site