On Fri, 28 Apr 2000, Jeremy Fitzhardinge wrote:
> >
> > OK, care to describe the setup in details?
>
> To mount:
>
> 1. user types cd /net/hostname
> 2. host doesn't exist, so it calls lookup in the autofs filesystem
> 3. autofs passes a message to the daemon saying "create the tree under
> 'hostname'".
> 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.
> 1. daemon polls the kernel, asking for trees which are ready for expiration
> 2. for each tree, the autofs filesystem checks the last-used timestamp, and
> for anything which has been idle for a while, it traverses the dentry tree
> looking for busy dentries. It ignores the dentries which are busy because
> of mountpoints within the tree.
> 3. kernel returns the candidate to the daemon, blocking any further user access
> to that tree
> 4. the daemon umounts all the filesystems in the tree and deletes the
> mountpoint(s)
> 5. goto 1
>
> In other words the autofs filesystem is structured as a number of trees rooted
> in the top-level dir. Each tree is treated as a single unit which is either
> mounted or umounted atomically with respect to the rest of the system.
[snip]
> How common is it that someone doesn't have control over how /home is mounted,
> but does have physical access to the cdrom drive and is allowed to mount it
> anywhere they want? Any admin who sets up an autofs /home isn't going to
s/cdrom/loopback of CD image over NFS/, for one.
> allow users to mount a cdrom under /home - they're going to set up a /mnt (or
> even /mnt/user) directory. And if you can mount the cdrom anywhere, then you
> can put it anywhere else in the namespace.
>
> This strikes me as a rather over-contrived example. In the last year of doing
> autofs4 development, nobody has ever mentioned that they found the way it works
> limiting in practice - in fact your's is the first theoretical objection.
>
> 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?
> >> It could be solved, I suppose, by having automount keep a list of the
> >> filesystems its responsible for, but that has the risk of getting out of
> >> sync with the system state and confusing things (a chronic problem with
> >> Sun's automounter). One of the design criteria was insisting that
> >> automount not keep private state, but be able to adapt to the system
> >> state.
> >
> > Eww... Why not pass the flag to mount and let the kernel remember that
> > these mountpoints are volatile?
>
> What flag? The filesystems are mounted with just the normal mount command, so
> there's no special mechanism to make the mount happen. Are you proposing
> adding a new mount flag so that mountpoints can be marked as
> volatile/non-volatile?
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.
-
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