I'd like to thank everyone in the chain between myself and
Brent (whoever they are). There are some very minor points in the
following which weren't EXACTLY true in our case, but nothing which
changes the overall validity of what Brent has to say.
Michael Lamoureux
lamour@mitre.org
=-=-=-=-=-=-=-=-> Cut Here <-=-=-=-=-=-=-=-=
From: brent@Eng.Sun.COM (Brent Callaghan)
Date: Wed, 23 May 90 15:24:49 PDT
Someone forwarded me your automounter posting. I don't know which
newsgroup it was.
There needs to be some explanation as to how the automounter uses the
information in its maps.
The automounter gets mounted at one or more mountpoints in your filesystem
just like any remote NFS server. The kernel is unaware that the NFS
requests being sent to this "server" are actually going to a local daemon.
At an indirect mountpoint the automounter behaves as if it is a directory
of symbolic links. On receiving an NFS lookup request from the kernel
the automounter checks to see whether the name refers to something that
is already mounted, or whether it needs to be mounted.
If it is already mounted (somewhere in /tmp_mnt) it just returns a
symbolic link to the real mountpoint in /tmp_mnt. This action effectively
removes the automounter from further work - the kernel follows the
symlink into /tmp_mnt and goes about its business without having to bother
the automounter any further. The automounter responds to such lookup's
very quickly - it just blindly returns a symbolic link. If the link
points to a mountpoint for a dead server, that's too bad. The automounter
is unaware of the status of the server. The automounter will continue to
do this until the symbolic link expires (not referenced for 5 min). The
symlink becomes invalid and the automounter attempts to unmount the
filesystem in /tmp_mnt. If it's EBUSY (a process may have cd'ed there),
it extends the expiration time 5 another 5 min.
If the lookup refers to something that is not mounted, the automounter
then checks the map. The map is referenced only if a lookup is received
for a filesystem that is NOT mounted. The map entry is gotten either
as the result of reading a local file, or from a ypmatch to a NIS map.
If you modify a map entry (local file or NIS map) the automounter will
use the new information when it next needs to do a mount.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you modify an entry for a filesystem that is already mounted, the
modification will have no effect until the next unmount/mount cycle.
This could take a long time if the filesystem is continuously busy e.g.
you are running your shell from it, or if its your home directory.
There's nothing the automounter can do to unmount a filesystem that
is in-use.
You can force the new information to take effect if you use the umount
command to unmount the filesystem(s) in /tmp_mnt and send the
automount daemon a SIGHUP. On receiving the signal the automounter
will read the /etc/mtab file and discover that some if its mounts
are unmounted. It will then invalidate the symbolic links that point
to these mountpoints and (in 4.1) print a console message acknowledging
the unmounts. If you then make a filesystem reference that hits the
modified entry you'll get the mount you want.
For both direct and indirect maps you can modify an existing entry
and the modification will take effect as described above.
Additionally, you can add/delete entries in an indirect map and they'll
take effect just as modifications do. Of course if you add a new entry
you don't have to worry about existing mounts so you can use it
immediately.
Direct maps have a restriction: if you add a new entry it won't be used
until the automounter is restarted. When the automounter is started it
reads every entry in a direct map in order to mount the daemon at all
the mountpoints therein. This daemon mounting only happens at automounter
startup. Similarly, if you delete an entry the automounter will not
automatically unmount the daemon from the mountpoint that corresponds
to the entry - you'll get "file not found" if you reference it.
I recommend that indirect maps be used whenever possible. They are not
subject to the update restriction described above and are less of an
overhead on your system (a direct map requires one daemon mount per entry).
Brent Callaghan
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT