On Wed, Jun 07, 2000 at 12:51:36AM -0400, Alexander Viro wrote:
On "union mounts".
We must first have a theory on what "union mount" means.
Union is a commutative operator, but here there is no symmetry
at all, so "union" is a misnomer. There is an order.
One might consider partial orders, so that one obtains a tree of mounts,
but I do not know any applications, and there is the problem of naming.
So, for simplicity, maybe there is a linear order.
Things happen in the top one. All others are read-only.
> A) suppose we have a bunch of filesystems union-mounted on
> /foo/bar. We do chdir("/foo/bar"), what should become busy? Variants:
> mountpoint, first element, last element, all of them.
Last element.
> B) after the action in (A) we add another filesystem to the set.
> Again, what should happen to the busy/not busy status of the components?
Previous top one has now become busy. All other were busy already.
> C) we start with the normal mount and union-mount something else.
> Question: what is the desired result (almost definitely the set of old and
> new mounted stuff) and who should become busy?
First element now is busy.
> D) In the cases above, what do we want to get from stat(2)?
stat(2) on this directory looks at the top one
> E) What do we want to do if we do normal mount atop of the
> union-mount? Variants: try to replace,
No. Very strange semantics for a mount.
> return -EBUSY.
Yes, quite reasonable. But I would prefer the third: just succeed.
We have a file hierarchy, and do a mount - well, we already know what that means,
and we just do it.
[I would prefer to return -EBUSY only when the same filesystem was already
mounted (in the same way) on the same mount point.]
> Doing replace (i.e.
> if everything can be umounted - do it and mount the new fs in place of
> the union) is attractive - we probably might treat the normal mount same
> way, which kills the "I've clicked in my point'n'drool krapplication ten
> times and it mounted CD ten times, waaaaaah" bug reports. Disadvantage:
> may need small fixes to mount(8) (basically, "if we already have mtab
> entry for this mountpoint and mount succeeds - discard the old one").
I think mount(8) is irrelevant. There have never been guarantees on /etc/mtab.
And none on /proc/mounts either. We just do a best effort.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:14 EST