Permalink
Cannot retrieve contributors at this time
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
autofs/README.active-restart
Go to fileThis commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
114 lines (90 sloc)
4.79 KB
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |