On Wed, May 23, 2007 at 08:36:04AM +0200, Miklos Szeredi wrote: > > 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? > When doing recursive bind on ancestor, these mounts are skipped. What about clone copying your namespace? What about MNT_SLAVE stuff being set up prior to that lookup? 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... > > 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'm not saying that it's unfeasible or won't lead to interesting things, but it really needs semantics done right... - 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
