|author||Cy Schubert <cy@FreeBSD.org>||2016-08-31 00:08:49 +0000|
|committer||Cy Schubert <cy@FreeBSD.org>||2016-08-31 00:08:49 +0000|
Suggested by: pfg@ Obtained from: ftp://ftp.am-utils.org/pub/am-utils/
Notes: svn path=/vendor/amd/dist/; revision=305100 svn path=/vendor/amd/6.2/; revision=305101; tag=vendor/amd/6.2
Diffstat (limited to 'README.autofs')
1 files changed, 176 insertions, 0 deletions
diff --git a/README.autofs b/README.autofs
new file mode 100644
@@ -0,0 +1,176 @@
+# This file is README.autofs
+# Erez Zadok <ezk AT cs.columbia.edu> a.k.a. "Darth Autoconf"
+# modified by
+# Ion Badulescu <ib42 At cs.columbia.edu> 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.
+- [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
+- 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.
+- 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.
+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.