> > > 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
