On Wed, 7 Jun 2000, Alexander Viro wrote:
> 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.
The key question, presumably, is which FSs can we unmount from the union
without /foo/bar breaking? If all the FSs can be unmounted safely, none
should be busy.
> 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?
Everything which could be unmounted safely is non-busy.
> 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?
Desired result: union of old and new FSs, nothing should be busy unless it
can't be unmounted safely.
> D) In the cases above, what do we want to get from stat(2)?
Good question ;-)
> E) What do we want to do if we do normal mount atop of the
> union-mount? Variants: try to replace, return -EBUSY.
I'd take the -EBUSY option.
> 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.
Making the point'n'drool krapplication fail the second time it tries to
mount anything makes more sense, IMO - that way, however much the user
points and/or drools, they only have one thing mounted. (Ideally, the
krapplication in question should tell them off, but that's up to the
author...)
Point&drool at "mount CDROM" once: /dev/cdrom gets mounted.
Point&drool a second time: Error, you can't mount it again.
Point&drool at "unmount CDROM" once: /dev/cdrom gets unmounted again.
Seems logical, IMO?
> 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").
Easier approach: First attempt to mount /dev/foo on /home/luser succeeds.
Second attempt fails, since there's already something there (unless it's a
union mount you want).
> 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.
Yep, that sounds right.
> 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.
It looks like it needs another exploder or two, perhaps?
-
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:28 EST