Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > On Wed, Aug 14, 2013 at 11:45 PM, Eric W. Biederman > <ebiederm@xxxxxxxxxxxx> wrote: >> Miklos Szeredi <miklos@xxxxxxxxxx> writes: >> >> Part of me does prefer the semantics Andy has suggested where instead of >> unmounting things we have something like a skeleton of the mount tree >> unioned with dcaches of the filesystems themselves. With "struct >> mountpoint" we are amazing close to that already. > > Two possible nasty cases: > > 1. mount whatever /tmp/foo/bar; rmdir /tmp/foo/bar; rmdir /tmp/foo > > Presumably ls /tmp shouldn't show foo. Should cd /tmp/foo/bar work? > What about umount /tmp/foo/bar? What about cd /tmp/foo? You have to have two mount namespaces or at least two different paths to to the same filesystem to make this work. rdir /tmp/foo/bar where /tmp/foo/bar is a mountpoint in your mount namespace will not work because you are trying to remove a root directory. So the semantics I would expect to see if it was implementable is /tmp/foo and /tmp/foo/bar would continue to exist on the paths where /tmp/foo/bar was a mount point and would disappear as soon as it was unmounted. > 2. mount whatever /tmp/foo; rmdir /tmp/foo; mkdir /tmp/foo > > Ugh. Likewise. I would expect to see the new /tmp/foo slide under the old /tmp/foo mountpoint. Essentially my expectation would be that the mount points would float over the filesystems. Semantically I like it, and have played with the idea before. Implementation wise shrug I didn't realize any of this was close to being practically implementatable until today. Eric -- 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
