On 29-Apr-2000 Alexander Viro wrote:
>> 4. daemon creates /net/hostname and any other mountpoints under it, and
>> mounts
>> the appropriate filesystems
>
> Here, please. Are these mountpoints in autofs tree? If that's the case -
> fine. If, however, you can get foohost:/ on /net/foohost and foohost:/usr
> on /net/foohost/usr - that's a different story.
It could be either. Generally it doesn't need to create the mountpoints if the
filesystems are mounted on each other, because its the filesystem tree exported
from another system.
>> Do you have a more substantial concern?
>
> It _really_ sounds wrong. I can see fs controlling the mountpoints
> situated in it. I can see userland telling VFS that mountpoint is volatile
> and fs asking VFS about volatile non-busy mountpoints under <foo>.
> I can (with some stretching) see the fs recognizing that it got the same
> kind of fs mounted on one of its directories and cooperating. But
> "everything in the tree under the fs of that type gets property foo, no
> matter what it is, who had mounted it there, yodda, yodda" sounds as a
> Wrong Thing(tm). VFS knows about the unified tree, but individual
> filesystem?
Well, it's not the in-kernel filesystem doing all this - it's the daemon which
implements the policy. The kernel doesn't need to worry about the "volatile"
flag on filesystems when working out expiration, because the daemon can work
that out (and has to, in fact, because its too complex to do in kernel mode).
Actually, the kernel doesn't need to know about a volatile flag at all, if
mount can take an option and store it in mtab (which works, so long as mtab
isn't a symlink to /proc/mounts). (Aside: wow, get_filesystem_info is really
ugly; why not just keep the string from the mount?)
> Yep. Moreover, with some work we could make figuring out how busy fs is
> _very_ cheap (O(1); mostly it's a matter of doing mntput() and dput() in
> right order). Then we could just export the list of stuff to be umounted
> through procfs/whatever.
With your new scheme of mounting things, does a mountpoint count as a reference
to a dentry? If not, then it should be pretty easy to look at the refcounts.
I don't really care what the mechanism is, so long as autofs can atomically
determine the busy-ness a set of filesystems.
There's no need to add more cruft to /proc. At present the expiration stuff is
done with an ioctl to the root of the autofs filesystem; you could also do it
with a magic file in autofs.
J
-
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 : Sun Apr 30 2000 - 21:00:16 EST