 |
|
|
| |
1 # This file is README.autofs
2 # am-utils-6.1
3 # Erez Zadok <ezk@cs.columbia.edu> a.k.a. "The Lord of Darkness"
4 #
5 # modified by
6 # Ion Badulescu <ib42@cs.columbia.edu> a.k.a. "The Autofs Master"
7
8 ** General notes about the autofs support in am-utils
9
10 - The autofs code in am-utils is gamma quality for Linux, beta quality for
11 Solaris 2.5+ and non-working for all the other systems.
12
13 - Link, lofs, ufs, nfs, nfsl, and auto mounts were tested and work properly;
14 the others should work, but were not tested.
15
16 * Caveats:
17
18 - [this applies to Solaris/IRIX 6/HP-UX/AIX] Amd acts as *both* automountd and
19 automount. There's no way to distinguish between the two. When amd starts,
20 it first registers itself as an autofs server (automountd's job), then
21 parses its own maps, and decides which autofs-type mounts to make
22 (automount's job). After the autofs mounts are made, amd listens for
23 requests from the kernel-based autofs, and acts upon them. Since there can
24 be only one autofs listener on a system, this means that automountd and amd
25 cannot run at the same time; nor can two amd's run at the same time if they
26 are both using autofs mounts.
27
28 - Linux support is available and fairly stable. Solaris 2.5+ support is
29 newer and less tested, but seems pretty stable as well. IRIX 6 and HP-UX
30 autofs support will probably be very easy once we get Solaris 2.5 to work,
31 as they use the same protocol and almost identical data structures. AIX
32 seems to be using the Solaris 2.5 protocol as well, but they don't provide
33 any headers or documentation so getting autofs to work will be tricky at best.
34
35 - Killing amd can become a problem if there are active mounts. Since mounts
36 are done "in place", we can't just unmount our mount points and go away. For
37 now, amd simply tells the kernel that it is dying; we need to think this
38 further. It would be nice to "take over" the old mountpoints, there is
39 support for this in Solaris (due to is RPC nature) and is easy to add to
40 the Linux kernel (an ioctl on the mountpoint).
41
42 - The Solaris 2.5 implementation of the autofs v1 protocol is NON-REENTRANT,
43 and ignoring this limitation results in a DEADLOCK between the kernel and
44 the daemon. This is a serious problem, although only for the lofs and link
45 mount types. In other words, suppose the daemon is trying a lofs/link mount
46 whose destination crosses another autofs mountpoint. If that mountpoint is
47 not yet mounted, it will trigger another autofs lookup which will deadlock
48 inside the kernel -- because the kernel is waiting for the previous request
49 to return. This is not even something specific to amd, Sun's own automountd
50 has the exact same problem. Ctrl-C breaks the deadlock, so it's not fatal,
51 but the lofs/link entry is in effect unusable.
52
53 - Solaris 2.8 (at least) doesn't like getting to get out-of-order replies to
54 mount requests, and ignores the late ones. It's only a minor annoyance (read
55 delay), because the RPC is retried by the kernel and it succeeds the second
56 time around.
57
58 * Solaris:
59
60 - Amd w/ autofs mounts will fight over the listener port with Sun's
61 automountd, so running both simultaneously is a really bad idea.
62
63 - Browsable_dirs is possible and implemented for Solaris 2.6+.
64
65 - Direct mounts are implemented and work correctly.
66
67 - Host maps are implemented and work correctly.
68
69 - On Solaris 2.6+, symlinks over autofs are inefficient. The kernel seems to
70 time them out immediately after receiving them, so each access to a
71 symlink causes a call to userspace. Needless to say, this negates the
72 whole point of using autofs. Automountd seems to always use lofs mounts
73 instead of symlinks, we do the same unless the admin requests
74 "autofs_use_lofs = no" in amd.conf.
75
76 - Solaris 2.5/2.5.1 do not support symlinks over autofs, so links are always
77 mounted as lofs mounts, subject to the limitation described in the caveats
78 section above.
79
80 - Restarting autofs mounts is possible, but not yet implemented.
81
82 * Linux:
83
84 - Amd should work fine even when the Linux automounter is running, the
85 mechanism being used prevents any kind of (evil) interaction between them.
86
87 - Browsing is not available if autofs support is used, due to limitations in
88 the kernel<->daemon protocol used by Linux 2.2 and 2.4. Only already-mounted
89 nodes will appear in the autofs directory, and this is implemented entirely
90 in the kernel.
91
92 - Host maps are supported with all autofs versions.
93
94 - Direct maps cannot be supported since there is no kernel support for them;
95 we might be able to get something eventually, but don't hold your breath.
96 If anything, we may do it using a regular NFS mountpoint and bind-mount on
97 top of it.
98
99 - Inherit doesn't make much sense because we can't restart a hung autofs
100 mount point, due to kernel limitations. This needs to be fixed in the
101 Linux kernel; it's not particularly difficult, and we might provide a
102 patch at some point.
103
104 - Link (and lofs) mounts will use the new bind-mount support in Linux
105 2.4+. No more symlinks! And /bin/pwd works great too.
106
107 - Auto maps are actually mounted as a separate autofs filesystem. Since each
108 autofs filesystem consumes 2 file descriptors, and amd has at most 1024
109 file descriptors available, there can be at most 512 of them mounted at
110 the same time. Because of this, extensive use of auto maps is discouraged
111 when using autofs on Linux.
112
113 * amd.conf requirements:
114
115 To tell amd to use an autofs-style mount point and mounts for a map, add
116
117 mount_type = autofs
118
119 either to the global section, or to the sections of the individual maps you
120 selected. Mixing autofs and normal amd mount points in the same amd.conf
121 file *does* work.
122
123 * Map changes:
124
125 No changes are necessary. If a map is marked as autofs in amd.conf, mounts
126 are done "in place" and the "fs" parameter is ignored most of the time.
127
128 * Todo:
129
130 We are looking for volunteers to improve the autofs code!
131
132 (1) These fixes are needed:
133
134 - sublinks are broken
135
136 - when the mount type is 'link', transparently translate it into a loopback
137 file system mount (lofs), that would mount in place, rather than supply a
138 symlink, at least on systems whose autofs doesn't support symlinks. Linux
139 does support symlinks, Solaris 2.6+ does too, but Solaris 2.5/2.5.1 doesn't
140 and neither does IRIX 6. Moreover, Sun's automountd always uses lofs for
141 link mounts, even on 2.6+, because symlinks are not cached in the kernel and
142 thus are not particularly efficient. [done]
143
144 - complain if certain incompatible options (autofs and ...) are used. Direct
145 maps on Linux is one such case of incompatible options. Browsable_dirs on
146 Linux is another such case.
147
148 - if amd is killed or dies, the autofs mounts will remain intact as required
149 (your system is _not_ hung, yay!). However, if you restart amd, it will not
150 correctly 'restart' the autofs mounts as the Sun automounter does. Rather,
151 it might cause another mount to happen, which leaves your /etc/mnttab
152 cluttered with older mounts entries which cannot be unmounted. It might also
153 just pretend everything is ok, when in fact it isn't.
154
155 (2) Code expansion:
156
157 - [Solaris only] implement the sockets version of amu_get_autofs_address()
158 and create_autofs_service(), in conf/transp/transp_sockets.c. Not sure if
159 it's necessary, Solaris it still biased towards TLI/STREAMS in
160 userspace. [mostly done, untested, might be used on AIX 5.x+ and IRIX 6]
161
162 - Implement the restarting of autofs mount points. This is already doable on
163 Solaris; on Linux, the kernel needs to be patched to allow it.
164
165 (3) Testing and porting to other systems:
166
167 - nothing has been tested on IRIX 6, which reportedly has a similarly
168 functioning autofs to Solaris 2.5. The code compiles, but has not been run
169 yet and is most likely broken.
170
171 - support for Linux autofs is stable, we need testers!
172
173 - support for Solaris 2.6+ is pretty stable, so we need testers for it, too!
174
175 - we did not test any version of Solaris on x86. It will probably work, but
176 you have been warned. Testers are welcome.
