Messages in this thread | | | Subject | Re: [RFC PATCH] file as directory | From | Miklos Szeredi <> | Date | Wed, 23 May 2007 09:19:17 +0200 |
| |
> > > 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/
| |