On Thu, May 12, 2011 at 11:10 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > > Okay, I'm definitely getting the hang of how this works. I like the way you > can just blat it over a pile of co-rooted R/O mounts and it will use all of > them as sources, in reverse order of mounting. However... > > /** > * build_root_union - Create the union stack for the root dir > * @topmost_mnt - vfsmount of topmost mount > * > * Build the union stack for the root dir. Annoyingly, we have to traverse > * union "up" from the root of the cloned tree to find the topmost read-only > * mount, and then traverse back "down" to build the stack. > > Why? > > Shouldn't you just start from the mount at the top of the pile and work > upwards through mnt_parent? There is an excellent and simple proof of the necessity of this which is too large to fit in the margin of this paper... Seriously, I remember trying to do it the "simple" way, writing a lot of buggy code, understanding why it would never work - and then, I thought, writing good comments and commit messages explaining why. Apparently not. All I can say is try it yourself and either it will work or it won't, in which place write better comments than I did. I think it was related to vfsmount_lock order and copy_tree(). > If the mount in the pile is not R/O, then you > can't include it, right? Surely, it would make most sense to just give an > error if the mount on which you're going to mount directly (and so is at the > top of the pile) is _not_ R/O... We might even go as far as to say that any > R/W mount in the pile is grounds for rejecting the union mount. > > As it is, you don't include _all_ R/O mounts in the stack - merely that slice > of them that is the uppermost contiguous set of R/O mounts. > > That way it's least surprising to people who try to do it wrong. If they try > to throw a R/W mount in there, they get an error and a line in dmesg. This is a user interface decision, and I contemplated doing it several other ways as well. The question is, how do you elegantly express the desire for N mounts to be unioned together in some particular order? I believe the best way to do this is: * Create a fresh mountpoint, e.g., /union * Mount the read-only mounts at /union in the order you want (with submounts as desired) * Mount the read-write layer at /union, which causes all the underlying mounts at that place in the namespace to be included * Pivot/move/relocate that mount as necessary Now, you can instead say the stopping point is "the first mount that is not union-able" instead of the all of the things mounted at this mountpoint. That's fine, it's a user interface decision, not anything to do with the inherent logic. Either solution is much preferable to the "mount -o upper=/mnt1,lower=/mnt2" kind of interface, in my opinion. -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
