Re: exact semantics of union mounts (and TRYEMULROOT)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Perhaps; but unless I'm gravely mistaken the way union mounts are
> meant to work in general is to find the topmost object with the
> requested name and operate on it, and if there is no such object
> operate on the creation layer.

That's not what I thought they were supposed to do.  Nor is it what you
want if you want to address the desire I thought union mounts were
designed to address.

Of course, I neither designed nor implemented union mounts, in NetBSD
or anywhere else, so it's entirely possible I am incorrect in what I
think about the intent behind them.  But the desire I see behind them
is, I think, a reasonable one to want to address, and the current
NetBSD semantics do, I believe, do a decent job of addressing it.

That desire is to take a read-only filesystem and, effectively, mount
it read-write, with all changes being performed in a second ("front")
layer.  In this case, you do not want to operate on the layer with the
object in it (well, you do for readonly operations; I'm really talking
about modifications, here).  You want to operate on the front layer.
That's why whiteouts exist: to provide something that can be done in
the front layer to make an existing back-layer object appear
nonexistent in the union view (this is, of course, necessary to support
unlink and rename).

The read-only back layer can be anything: an NFS mount, a CD-ROM, even
just a normal disk you happen to want to not write to.  Uses include
running with a writable root from a CD-ROM (the front layer could even
be a ramdisk), determining what changes some opaque piece of software
has done, or sharing the read-only part of a read-mostly filesystem.

That's why I think it would be good to preserve the current NetBSD
semantics, in the sense of continuing to make them available to admins
who want them.  And I don't see any way to do what I sketched above
with the kind of union mount you seem to be advocating.  So, as I think
I said upthread, if you want to implement mount -o plan9union or mount
-t plan9union, knock yourself out, but I think it would be good to
continue to support the current semantics.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B