OK, folks, I've got _something_ that looks more or less like
union-mount in a working state. IOW, lookup(), readdir() and friends work.
However, there is a bunch of stuff that should settle down before it will
go into the kernel. Most of the questions are not about the implementation,
they are about functionality we want from this animal. Current pre-alpha
patch implements more or less random set of answers to the quesitons
below, but that should be dealt with before anything will go anywhere near
the tree.
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.
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?
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?
D) In the cases above, what do we want to get from stat(2)?
E) What do we want to do if we do normal mount atop of the
union-mount? Variants: try to replace, return -EBUSY. 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").
Frankly, I'm sorely tempted to say that cd to mountpoint always
makes the mountpoint busy and leaves the mounted fs alone. IOW, if we
have / on /dev/foo and /usr on /dev/bar then opening /usr/bin should make
bar busy (as it does now), but opening /usr should make _foo_ busy.
Benefits: makes for easy, consistent logics with union-mounts
(nothing has to be changed whatever we add to/remove from the set, no
ambiguity wrt what can be umounted, etc.).
Losses: differs from the current behaviour, may confuse some
programs. Notice that all difference is in treatment of mountpoint/root -
everything else works as usual.
Comments and flames to fsdevel and l-k, conspiracy theories to
alt.usenet.kooks and /dev/null on localhost, please - spare the vger
bandwidth.
-
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 : Wed Jun 07 2000 - 21:00:27 EST