I'm curious about this. We have had a situation where our automounter daemon (amd on hpux10.20) has been chewing up CPU trying to resolve a mount to a filer:
Aug 13 21:30:00 build034 amd[4993]: No mount point for /remote/ronco/vol/vol1 - skipping Aug 13 21:30:00 build034 amd[552]: "/nfs/ronco.unx.sas.com" on /remote/ronco sti ll active Aug 13 21:34:27 build034 amd[5426]: No mount point for /remote/ronco/vol/vol1 - skipping Aug 13 21:34:27 build034 amd[552]: "/nfs/ronco.unx.sas.com" on /remote/ronco sti ll active
This is showing up *hundreds of thousands of times* in the syslogs, and is causing out automounter daemon to take a 50-60% of the CPU across hundreds of workstations, if not thousands and filling disks with syslog entries. Our exports are:
/ -root=server2:server3 /home -root=server2:server3 /builddir -root=server2:server3 /vol/vol1 -root=server2:server3
Note that /vol/vol1 does exist.
So, I read on the NOW site what I have pasted below. The second to the last paragraph is what seems to stand out to me - "If you use paths of the / form for export points in the root volume, the automounter might not be able to mount directories in other volumes, or it might create new directories in your root volume to serve as mount points."
We are planning on changing the exports to:
/vol/vol0 -root=server2:server3 /vol/vol1 -root=server2:server3
this weekend and rebooting all machines (and changing references from /nfs/filer/builddir to /nfs/filer/vol/vol0/builddir...). We are *really* hoping that this fixes the amd problem. Any thoughts about whether this is going to work or not... or if something else might be causing our automounter problem???? Note that we have this problem only with the filer ronco. The other filers at 5.01 do not have /vol/vol1 yet.
Thanks,
Kelly
Data ONTAP 5.0R2
Export point notation
Both / and /vol/vol0 identify the root volume. You can use either form to list exported directories in /etc/exports. For most purposes, the two forms are equivalent. However, when an NFS client requests a list of export points from the filer (for instance, as the result of a showmount -e command), the filer returns the paths exactly as they appear in /etc/exports. This affects the behavior of the automounter. For example, if toaster exports /, the automounter mounts the root volume for toaster on /net/toaster, but if it exports /vol/vol0, the root volume appears in /net/toaster/vol/vol0.
If you have more than one volume, use paths of the /vol/vol0 form for all your export points in the root volume. If you use paths of the / form for export points in the root volume, the automounter might not be able to mount directories in other volumes, or it might create new directories in your root volume to serve as mount points.
Note that /vol/ is not a valid syntax for filers
This is showing up *hundreds of thousands of times* in the syslogs, and is causing out automounter daemon to take a 50-60% of the CPU across hundreds of workstations, if not thousands and filling disks with syslog entries. Our exports are:
/ -root=server2:server3 /home -root=server2:server3 /builddir -root=server2:server3 /vol/vol1 -root=server2:server3
Note that /vol/vol1 does exist.
It might be that some automounters can't cope with that - the problem may be that "/vol/ is not a valid syntax for filers", and the automounters in question try to mount "/vol", fail, and complain - but it's also possible to have e.g. a UNIX box with "/foo/bar" and "/bletch" exported but with "/foo" not exported, which might look the same to an automounter, although the error it'd get back from the server when it tries to mount "/foo" might be different from the one it gets from trying to mount "/vol" on a filer.
It'd be interesting to tweak the "amd" source to see why it fails to mount "/remote/ronco/vol/vol1", and to see what operations it's trying to do and which one fails.
But that'd ultimately be an automounter problem, not a pure filer problem with "/vol/<volume name>/XXX" vs. "/XXX". I think Jim Davis had a one-volume machine, in which case his export list wouldn't have a mix of those two types of pathnames, so I wouldn't expect an automounter to trip over that.
So, I read on the NOW site what I have pasted below. The second to the last paragraph is what seems to stand out to me - "If you use paths of the / form for export points in the root volume, the automounter might not be able to mount directories in other volumes,
...which shouldn't apply if you don't *have* other volumes...
or it might create new directories in your root volume to serve as mount points."
...which presumably means that if it mounts "foobar:/" on "/net/foobar", and mounts "foobar:/home" on "/net/foobar/home" (not necessarily a pointless exercise, if the options checked at NFS-operation time, such as "ro" and "rw=" and "anon=", are different for "/home" than for "/), it'd try making a "/net/foobar/vol" directory, and a "/net/foobar/vol/vol1" directory under it, to mount "foobar:/vol/vol1".
If so, that also shouldn't apply if you don't have other volumes.