Re: exact semantics of union mounts (and TRYEMULROOT)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Jul 12, 2017 at 12:54:31AM +0700, Robert Elz wrote:
 >   | In Plan 9 the layer creations happen in is chosen by a mount flag, and
 >   | isn't necessarily the top layer. We don't have that flag (but could
 >   | add it, as I noted) - my original mail was using "not readonly" as a
 >   | proxy for it.
 > 
 > That's a poor choice - adding a "which layer" option would not be terrible,
 > but in the absence of that. "top layer" is the rational solution, not
 > "some random layer that happens to seem to work".

Fair enough; we should add the option.

 >   | How do you propose to get back to the top level without starting at
 >   | the top again?
 > 
 > This may be a question of word interpretation, to me "start again" means
 > repeat what you have just done from the beginning, here what we are doing
 > is something totally different, we simply go to the layer in which the
 > file is to be created (the top layer as it is at the minute) and (attempt to)
 > create the the file there, nothing like the previous search to see if the
 > file exists, so no "again" and not "start" either, as it is just step 2
 > of the process.

I guess. I think it's actually a question of framing arising from
having been looking at the implementation vs. not. Crossing a mount
point (even in a union stack) isn't a trivial operation and being able
to go back to the top of the stack has implications, for locking if
nothing else.

I don't think we actually disagree.

 >   | Wrong... Plan 9 doesn't have whiteouts.
 > 
 > But NetBSD does (in at least most filesystems) - I suspect quite a lot of
 > the naming sematics are not identical between NetBSD (and unix systems in
 > general) and Plan 9, and regardless of which is better, simply attempting 
 > to shoehorn one small piece of Plan 9 into NetBSD isn't going to work well.

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.

(I don't think there's anything to be gained by having NetBSD's be
subtly different.)

Changing that to stuff a whiteout into the creation layer for deletes
doesn't seem desirable, especially since if the creation layer isn't
the top it might stuff the whiteout *under* the object you're trying
to remove :-)

-- 
David A. Holland
dholland%netbsd.org@localhost