> > When a non-directory object is accessed without a trailing slash, then > > path resolution returns the object itself as usual. > > > > If a non-directory object is accessed with a trailing slash, then the > > filesystem may opt to let the file be accessed as a directory. In > > this case "something" (as supplied by the filesystem) is mounted on > > top of the non-directory object. > > > > This mount will have special properties: > > > > - If there's no trailing slash is after the file name, the mount > > won't be followed, even if the path resolution would otherwise > > follow mounts. > > > > - The mount only stays there while it is referenced by some external > > object, like a pwd or an open file. When it is no longer > > referenced, it is automatically unmounted. > > > > - Unlike "real" mounts, this won't block unlink(2) or rename(2) on > > the underlying object. > > 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... When doing recursive bind on ancestor, these mounts are skipped. > 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. > I'll look through the patch tonight; it sounds interesting, assuming that > we don't run into serious crap with locking and <shudder> revalidation > logics. Revalidation shouln't be a problem. We'll just end up with an unhashed dentry with a mount over it, which will be detached when the vfsmount ref is dropped. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
