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.
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 23 2000 - 21:00:13 EST