[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: exact semantics of union mounts (and TRYEMULROOT)
> 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
Main Index |
Thread Index |