From ca57057f598bfc7119f79f71bf38ec88244ab396 Mon Sep 17 00:00:00 2001 From: Cy Schubert Date: Wed, 31 Aug 2016 00:08:49 +0000 Subject: Import am-utils 6.2, Suggested by: pfg@ Obtained from: ftp://ftp.am-utils.org/pub/am-utils/ --- README.autofs | 176 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 README.autofs (limited to 'README.autofs') diff --git a/README.autofs b/README.autofs new file mode 100644 index 000000000000..6f5cc90f7f07 --- /dev/null +++ b/README.autofs @@ -0,0 +1,176 @@ +# This file is README.autofs +# am-utils-6.1 +# Erez Zadok a.k.a. "Darth Autoconf" +# +# modified by +# Ion Badulescu a.k.a. "The Autofs Master" + +** General notes about the autofs support in am-utils + +- The autofs code in am-utils is gamma quality for Linux, beta quality for + Solaris 2.5+ and non-working for all the other systems. + +- Link, lofs, ufs, nfs, nfsl, and auto mounts were tested and work properly; + the others should work, but were not tested. + +* Caveats: + +- [this applies to Solaris/IRIX 6/HP-UX/AIX] Amd acts as *both* automountd and +automount. There's no way to distinguish between the two. When amd starts, +it first registers itself as an autofs server (automountd's job), then +parses its own maps, and decides which autofs-type mounts to make +(automount's job). After the autofs mounts are made, amd listens for +requests from the kernel-based autofs, and acts upon them. Since there can +be only one autofs listener on a system, this means that automountd and amd +cannot run at the same time; nor can two amd's run at the same time if they +are both using autofs mounts. + +- Linux support is available and fairly stable. Solaris 2.5+ support is +newer and less tested, but seems pretty stable as well. IRIX 6 and HP-UX +autofs support will probably be very easy once we get Solaris 2.5 to work, +as they use the same protocol and almost identical data structures. AIX +seems to be using the Solaris 2.5 protocol as well, but they don't provide +any headers or documentation so getting autofs to work will be tricky at best. + +- Killing amd can become a problem if there are active mounts. Since mounts +are done "in place", we can't just unmount our mount points and go away. For +now, amd simply tells the kernel that it is dying; we need to think this +further. It would be nice to "take over" the old mountpoints, there is +support for this in Solaris (due to is RPC nature) and is easy to add to +the Linux kernel (an ioctl on the mountpoint). + +- The Solaris 2.5 implementation of the autofs v1 protocol is NON-REENTRANT, +and ignoring this limitation results in a DEADLOCK between the kernel and +the daemon. This is a serious problem, although only for the lofs and link +mount types. In other words, suppose the daemon is trying a lofs/link mount +whose destination crosses another autofs mountpoint. If that mountpoint is +not yet mounted, it will trigger another autofs lookup which will deadlock +inside the kernel -- because the kernel is waiting for the previous request +to return. This is not even something specific to amd, Sun's own automountd +has the exact same problem. Ctrl-C breaks the deadlock, so it's not fatal, +but the lofs/link entry is in effect unusable. + +- Solaris 2.8 (at least) doesn't like getting to get out-of-order replies to +mount requests, and ignores the late ones. It's only a minor annoyance (read +delay), because the RPC is retried by the kernel and it succeeds the second +time around. + +* Solaris: + +- Amd w/ autofs mounts will fight over the listener port with Sun's + automountd, so running both simultaneously is a really bad idea. + +- Browsable_dirs is possible and implemented for Solaris 2.6+. + +- Direct mounts are implemented and work correctly. + +- Host maps are implemented and work correctly. + +- On Solaris 2.6+, symlinks over autofs are inefficient. The kernel seems to + time them out immediately after receiving them, so each access to a + symlink causes a call to userspace. Needless to say, this negates the + whole point of using autofs. Automountd seems to always use lofs mounts + instead of symlinks, we do the same unless the admin requests + "autofs_use_lofs = no" in amd.conf. + +- Solaris 2.5/2.5.1 do not support symlinks over autofs, so links are always + mounted as lofs mounts, subject to the limitation described in the caveats + section above. + +- Restarting autofs mounts is possible, but not yet implemented. + +* Linux: + +- Amd should work fine even when the Linux automounter is running, the + mechanism being used prevents any kind of (evil) interaction between them. + +- Browsing is not available if autofs support is used, due to limitations in + the kernel<->daemon protocol used by Linux 2.2 and 2.4. Only already-mounted + nodes will appear in the autofs directory, and this is implemented entirely + in the kernel. + +- Host maps are supported with all autofs versions. + +- Direct maps cannot be supported since there is no kernel support for them; + we might be able to get something eventually, but don't hold your breath. + If anything, we may do it using a regular NFS mountpoint and bind-mount on + top of it. + +- Inherit doesn't make much sense because we can't restart a hung autofs + mount point, due to kernel limitations. This needs to be fixed in the + Linux kernel; it's not particularly difficult, and we might provide a + patch at some point. + +- Link (and lofs) mounts will use the new bind-mount support in Linux + 2.4+. No more symlinks! And /bin/pwd works great too. + +- Auto maps are actually mounted as a separate autofs filesystem. Since each + autofs filesystem consumes 2 file descriptors, and amd has at most 1024 + file descriptors available, there can be at most 512 of them mounted at + the same time. Because of this, extensive use of auto maps is discouraged + when using autofs on Linux. + +* amd.conf requirements: + +To tell amd to use an autofs-style mount point and mounts for a map, add + + mount_type = autofs + +either to the global section, or to the sections of the individual maps you +selected. Mixing autofs and normal amd mount points in the same amd.conf +file *does* work. + +* Map changes: + +No changes are necessary. If a map is marked as autofs in amd.conf, mounts +are done "in place" and the "fs" parameter is ignored most of the time. + +* Todo: + +We are looking for volunteers to improve the autofs code! + +(1) These fixes are needed: + +- sublinks are broken + +- when the mount type is 'link', transparently translate it into a loopback +file system mount (lofs), that would mount in place, rather than supply a +symlink, at least on systems whose autofs doesn't support symlinks. Linux +does support symlinks, Solaris 2.6+ does too, but Solaris 2.5/2.5.1 doesn't +and neither does IRIX 6. Moreover, Sun's automountd always uses lofs for +link mounts, even on 2.6+, because symlinks are not cached in the kernel and +thus are not particularly efficient. [done] + +- complain if certain incompatible options (autofs and ...) are used. Direct +maps on Linux is one such case of incompatible options. Browsable_dirs on +Linux is another such case. + +- if amd is killed or dies, the autofs mounts will remain intact as required +(your system is _not_ hung, yay!). However, if you restart amd, it will not +correctly 'restart' the autofs mounts as the Sun automounter does. Rather, +it might cause another mount to happen, which leaves your /etc/mnttab +cluttered with older mounts entries which cannot be unmounted. It might also +just pretend everything is ok, when in fact it isn't. + +(2) Code expansion: + +- [Solaris only] implement the sockets version of amu_get_autofs_address() +and create_autofs_service(), in conf/transp/transp_sockets.c. Not sure if +it's necessary, Solaris it still biased towards TLI/STREAMS in +userspace. [mostly done, untested, might be used on AIX 5.x+ and IRIX 6] + +- Implement the restarting of autofs mount points. This is already doable on +Solaris; on Linux, the kernel needs to be patched to allow it. + +(3) Testing and porting to other systems: + +- nothing has been tested on IRIX 6, which reportedly has a similarly +functioning autofs to Solaris 2.5. The code compiles, but has not been run +yet and is most likely broken. + +- support for Linux autofs is stable, we need testers! + +- support for Solaris 2.6+ is pretty stable, so we need testers for it, too! + +- we did not test any version of Solaris on x86. It will probably work, but +you have been warned. Testers are welcome. -- cgit v1.2.3