[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: exact semantics of union mounts (and TRYEMULROOT)
On Tue, Jul 11, 2017 at 02:25:16AM +0700, Robert Elz wrote:
> | Union mounts are complicated in this regard because when the directory
> | involved is a union mount point, some layer of the union mount needs
> | to be chosen to invoke the filesystem-level operation;
> I don't think so, directory ops all happen at the upper level (or nowhere).
I don't think that's what Plan 9 does but I'm willing to be shown I'm
wrong. That would be quite a bit simpler.
(it is also not what we currently do, not that what we currently do is
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.
I don't think deletes are restricted to that layer though.
> | Directory operations can be divided into five categories:
> | - lookup (ordinary directory traversal, operations like stat, open
> | without O_CREATE, etc.)
> | - nonexclusive create (open without O_CREATE)
> You mean without O_EXCL,
> | - exclusive create (mkdir, symlink, open with O_CREATE|O_EXCL, etc.)
> | - remove (rmdir, unlink)
> | - rename
> Forget rename(), the relevant operation is link() - rename is just
> link(),unlink() with idempotent semantics.
Same set of questions arises.
> | For lookup,
> Agreed, no question. And to answer mouse, if there's a whiteout found,
> the search terminates, and the file was not found.
> | For nonexclusive create, we should do the same, and if we run out of
> | layers start at the top again
> No, if the file does not exist, it is created, in the top level, there
> is no "start again"
How do you propose to get back to the top level without starting at
the top again?
> | Various security
> | properties depend on exclusive create actually being exclusive, and I
> | don't think having union mounts weaken this is healthy.
> Of course.
> | So I think we need to test all layers before creating anything.
> Of course.
> | (It also means we need to lock all layers,
> The top layer needs to be locked, and remain that way, I expect (though
> we just have a normal race if it is unlocked, then locked again later,
> only effect would be, I think, that the top directory would need to be
> checked again in case the file appeared in the meantime.) That is, anyone
> creating the same file name will put it in the upper layer, and it is
> just a question of who gets there first, which is something we do not need
> to answer, just make sure there is only one winner. If someone at the
> same time is creating a file in the alternative name for the under layer
> then "so what", that's not a problem.
Ok, so we don't need to lock the layers under the one where creation
happens, but that doesn't help much.
> | Once we've ascertained that the name doesn't exist, we use the topmost
> | read-write layer;
> Huh? Where does that come from? You use the upper layer. If for any
> reason the file cannot be created there, the operation fails. No second
> | For remove, I think the correct thing to do is to descend until we
> | find the topmost layer where the target name exists, if any,
> We look see if the file exists, yes, if not there is nothing to do (error.)
> | and then operate at that layer.
> No, all changes in the top layer, the file is "removed" by creating
> a whiteout, which will then cause any lookup to fail.
Wrong... Plan 9 doesn't have whiteouts.
David A. Holland
Main Index |
Thread Index |