On Wed, 7 Jun 2000, Petr Vandrovec wrote:
> 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...
Ouch. "All" means that we can't, e.g expire elements of union.
> > 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...
Why?
> > 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?
Erm... The _only_ question is handling of the (common) mountpoint -
everything else is obvious. There you have several directories joined, so
which should we ask about ->stat()?
> 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?)
You are mixing multiple mounting with having several filesystems mounted
on the same spot atop of each other (several > 2, obviously). And the
latter may be dropped - _nothing_ can possibly depend on that, it used to
be prohibited until several weeks ago.
> > 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
First of all, it may very well move, be deleted, etc.
> 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).
Sure it does. And will keep doing so - /usr/bin is not a root and
there is no ambiguity.
> If you mark foo busy, then cwd can move somewhere else,
> cannot it?
I'm not sure that I understand you right, but current directory
_may_ move. Try
% mkdir /tmp/foo
% cd /tmp/foo
% mv /tmp/foo /tmp/bar
% /bin/pwd
-
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