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 especially significant) 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, er right > | - 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 > chances. See above. > | 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 dholl...@netbsd.org
