I don't know enough about shared subtrees to have an opinion on what should happen with those, but you fundamentally asked about a perceived weirdness in existing Linux code, and I do have an opinion on that (which is that there's no weirdness).
>On analysis it turns out the culprit is the current rule which says >'expose the most-recent-mount and not the topmost mount' I don't think the current rule is "expose the most-recent-mount." I see it as "expose the topmost mount." I think the issue is what does "mount F over directory D" mean? Does it mean to mount F immediately over D, in spite of anything that might be stacked above D right now? Or does it mean to throw F onto the stack which is currently sitting over D? Your analysis assumes it's the former, whereas what Linux does is consistent with the latter. Neither of them actually makes sense. mount over "." simply doesn't make sense. Mount is a namespace operation. "mount over D" says, "when someone looks up name D, ignore what's really in the directory and instead give him this other filesystem object." "Mount over /mnt/cdrom" doesn't mean mount over the directory /mnt/cdrom. It means mount under the name "cdrom" in the directory /mnt. So "mount over '.'" means any future lookup of "." in that directory should hyperjump to the other mount. That's clearly not what anyone wants, so mount ought to recognize the special nature of the "." directory entry and not allow mounts over it. If you did that, and made mount into the namespace operation it's meant to be, there would be no such thing as inserting a mount into the stack, since you have no way to refer to the covered directory -- it's no longer in the namespace. I have no idea if that clarifies the shared subtree dilemma, but you ask if there's any pressing need for the current behavior, and I would have to say no, because a) neither behavior has any business existing; and b) I have a hard time imagining anyone depending on it. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
