On Fri, May 13, 2011 at 6:54 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > > Hmmm... > > | /** > | * clone_union_tree - Clone all union-able mounts at this mountpoint > | * @topmost: vfsmount of topmost layer > | * @mntpnt: target of union mount > | * > | * Given the target mountpoint of a union mount, clone all the mounts at that > | * mountpoint (well, pathname) that qualify as a union lower layer. ... > > Is this so that the unionmount can survive MS_BIND and MS_MOVE? Well, sort of - I said "Of course we can't bind mount a union mount" and Al said, "Why not?" and then proceeded to outline the above clone-all-mounts strategy. The radical shift of viewpoint that Al brought to this was that the stack of read-only mounts we constructed before the actual union mount are really just instructions to the kernel about what to union. We don't union those *actual specific* instances of the vfsmount structure, we use them to create a union mount tree that has cloned instances of those mounts in the order and position they appear in. Once the union mount is done, you can move that union mount around and the underlying read-only mounts will appear and can be unmounted, moved, etc. themselves - they no longer have any connection with the union. Solves a lot of nasty problems. > | * Returns error if any of the mounts or submounts mounted on or below this > | * pathname are unsuitable for union mounting. This means you can't construct > | * a union mount at the root of an existing mount without unioning it. > > If I understand this correctly, I'd rephrase this to be: > > * Returns an error if any of the stack of mounts or submounts currently > * mounted on @mntpnt are unsuitable for union mounting. This means you cannot > * construct a union mount over the root of an existing mount without including > * it in the union or having it prevent the union. Sure, that's correct. (But feel free to change the way that works if you see a better interface.) -VAL -- 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
