More questions on unionmount

More questions on unionmount

[David Howells]

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?  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.

David

Re: More questions on unionmount

[David Howells]

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?

|  * 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.

David

Re: More questions on unionmount

[Valerie Aurora]

On Fri, May 13, 2011 at 6:54 AM, David Howells <dhowells@redhat.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: More questions on unionmount

[Valerie Aurora]

On Thu, May 12, 2011 at 11:10 AM, David Howells <dhowells@redhat.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html