On 28-Apr-2000 Alexander Viro wrote:
> On Tue, 18 Apr 2000, Jeremy Fitzhardinge wrote:
>
>> I added this in order to support the common case of /net, where an NFS
>> server may export a tree of filesystems which autofs should treat as a
>> unit, atomically mounting and umounting. In other words, it treats all
>> filesystems mounted under /net/hostname as being a single tree, which is
>> why it traverses across mountpoints during the expire test.
>
> 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
5. when done, it sends back a worked/failed message to the kernel
6. kernel unblocks the user process, and lets the cd complete (either with
success or ENOENT).
To expire:
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.
>> In your example with /home, it will fail to remount ~/cdrom, because
>> you've manually interfered with its turf. It's really a matter of either
>> accepting the automation or doing things manually. If you want to mount
>> the cdrom in autofs controlled space, you should get autofs to manage it.
>
> Except that you may very well have autofs-served $HOME by external policy.
> In that case you are pretty much stuck.
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
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 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?
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