Followup to: <XFMail.20000418091804.jeremy@goop.org>
By author: Jeremy Fitzhardinge <jeremy@goop.org>
In newsgroup: linux.dev.kernel
>
> On 18-Apr-2000 Alexander Viro wrote:
> > Look: we have /home as autofs4 and /home/foo is NFS (mounted by
> > autofs, that is). Now, I want to mount a CD on ~/cdrom (where
> > $HOME==/home/foo).
> > No problem. Now I do cd /tmp, start something lengthy and walk away to
> > take some coffee. When I'm back I'm saying cd ~/cdrom, only to find out
> > that ~/cdrom is not mounted anymore. And autofs has no idea how to get
> > it
> > (surprise, surprise).
> > IMO it's a broken behaviour. I don't know whether you consider
> > following mountpoints during the expiry search as a feature, but in its
> > current form it looks rather like a bug. Scenario above is a Bad
> > Thing(tm). What do you actually want there?
>
> Yes, that is a problem you would face. The assumption is that under an
> autofs mountpoint, autofs gets to control the mounts and umounts. It
> doesn't use anything other than /etc/mtab to keep track of what's
> mounted, so it will umount manually mounted filesystems during an expire.
>
> 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.
>
> 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.
>
> 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.
>
Jeremy: now you know why I'm making the autofs v5 daemon multithreaded
rather than forking.
In the end, you really do need to keep state around.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot."- 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 23 2000 - 21:00:14 EST