On 7 Jun 00 at 0:51, 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.
Hi Al,
maybe that I'm too affected by Netware which allows you to do almost
nothing if you have something open, but...
> 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.
I believe that all of them. Or, we can make alternative and mark
none of them busy (together with Tigran yet-to-write force unmount) -
if there is reason why cwd should make filesystem busy at all...
> 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?
I believe that it should not be possible (to match with my reply to (A)).
Doing anything else looks suspicious to me.
> 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?
With or without (A)? Output should be merge of both filesystems. And if
mountpoint was busy before, union-mount should not suceed...
> D) In the cases above, what do we want to get from stat(2)?
>From `stat' or `statfs'? From `[lf]stat' I'd expect data about file on
which open/read/write will operate...
For `statfs', I have no idea... (I did not look what happens if you
create new file) Maybe data about filesystem which will be used for
new files?
> 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").
And can `mount' correctly distinguish whether it should discard old entries
(in this case) or left them alone (current multiple mounting)? I vote
for -EBUSY, you can emulate replace from userspace (with bunch of races,
I know, but does it matter for this case? If it matters, why we do not
have `replace mount' already?)
> 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.
It looks suspicious to me. I was under impression that `cwd' makes
cwd busy to make sure that current directory will not move somewhere
else (and it matches with old behavior - if process has /usr/bin as
cwd and you mount something to /usr, old process still works in
old /usr/bin). If you mark foo busy, then cwd can move somewhere else,
cannot it?
> Comments and flames to fsdevel and l-k, conspiracy theories to
> alt.usenet.kooks and /dev/null on localhost, please - spare the vger
> bandwidth.
Sorry, my system for reading mails does not have /dev/null (it is DOS
workstation) and my mail reader cannot do nntp :-( So I have to send it
to vger :-)
Best regards and sorry for wasting bandwidth,
Petr Vandrovec
vandrove@vc.cvut.cz
-
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