1#@!#!123s

: / usr / share / doc / autofs-5.0.7 /
Filename : README.active-restart
back
The problem
-----------

The initial release of autofs version 5 used the "umount -l" (lazy
umount) to clear stale mounts at startup so that new mounts could
be made with a clean slate. This proved to be a bad choice because
the lazy umount removes the mount from the kernel mount tree. While
the mount itself persists (invisibe to further VFS lookups) until
the mount isn't busy anymore the kernel function d_path(), used to
calculate the path from the mount point to the root, isn't able to
perform its function any more. This leads to things that use d_path(),
such as /bin/pwd, the contents of the link /proc/<pid>/cwd, and so on.

The actual problem with autofs is that it can't re-connect to existing
mounts. Immediately one thinks of just adding the ability to remount
the autofs file system would solve it, but that can't work. This is
because autofs direct mounts and the implementation of "on demand mount
and expire" of nested mount trees i(multi-mounts) have the file system
mounted directly on top of the mount trigger directory.

For example, there are two types of automount maps, direct (in the kernel
module source you will see a third type called an offset, which is just
a direct mount in disguise) and indirect.

Here is a master map with direct and indirect map entries:

/-      /etc/auto.direct
/test   /etc/auto.indirect

and the corresponding map files:

/etc/auto.direct:

/automount/dparse/g6  budgie:/autofs/export1
/automount/dparse/g1  shark:/autofs/export1
and so on.

/etc/auto.indirect:

g1    shark:/autofs/export1
g6    budgie:/autofs/export1
and so on.

For the above indirect map an autofs file system is mounted on /test and
mounts are triggered for each sub-directory key. So we see a mount of
shark:/autofs/export1 on /test/g1, for example.

The way that direct mounts are handled is by making an autofs mount on
each full path, such as /automount/dparse/g1, and using it as a mount
trigger. So when we walk on the path we mount shark:/autofs/export1 "on
top of this mount point".

But, each entry in direct and indirect maps can have offsets (making
them multi-mount map entries).

For example, an indirect mount map entry could also be:

g1  \
   /        shark:/autofs/export5/testing/test \
   /s1      shark:/autofs/export/testing/test/s1 \
   /s2      shark:/autofs/export5/testing/test/s2 \
   /s1/ss1  shark:/autofs/export1 \
   /s2/ss2  shark:/autofs/export2

and a similarly a direct mount map entry could also be:

/automount/dparse/g1 \
    /       shark:/autofs/export5/testing/test \
    /s1     shark:/autofs/export/testing/test/s1 \
    /s2     shark:/autofs/export5/testing/test/s2 \
    /s1/ss1 shark:/autofs/export2 \
    /s2/ss2 shark:/autofs/export2

One of the issues with version 4 of autofs was that, when mounting an
entry with a large number of offsets, possibly with nesting, we needed
to mount and umount all of the offsets as a single unit. Not really a
problem, except for people with a large number of offsets in map entries.
This mechanism is used for the well known "hosts" map and we have seen
cases (in 2.4) where the available number of mounts are exhausted or
where the number of privileged ports available is exhausted.

In version 5 we mount only as we go down the tree of offsets and
similarly for expiring them which resolves the above problem. There is
somewhat more detail to the implementation but it isn't needed for the
sake of the problem explanation. The one important detail is that these
offsets are implemented using the same mechanism as the direct mounts
above and so the autofs mount points can be covered by another mount.

To be able to restart autofs leaving existing direct, indirect and
offset mounts in place we need to be able to obtain a file handle
for these potentially covered autofs mount points. To do this the
autofs ioctl control implementation has been re-implemented,
providing the same functions as the existing ioctl interface and
new operations to the ability to open a file handle on a covered
autofs mount point.

In order to utilize the new interface both kernel and user space
changes (included in this release) are needed. The default install
of autofs won't use the new interface unless it is enabled in the
configuration. This can be done by setting "USE_MISC_DEVICE" to "yes"
in the autofs configuration. In addition, if selinux is being used,
it will likely need to allow operations on the autofs device file
or be set to permissive mode.

Patches for several recent kernel that don't have the implementation
can be found in the patches directory. They have "dev-ioctl" in their
name. Note that, to use these patches, you should be using a kernel
patched with all the current autofs bug fixes since, apart from porobably
not working, the patch probably won't apply either. The bug fix patches
can also be found in the patches directory and they have "v5-update" in
their names.

Ian