Sean O'Neill wrote: > Snoop ... I was messing with NFS mounts on a Mac client and the > mounts were taking quite a bit of time so I pulled snoop out. > > So even after I tuned /etc/default/nfs to max out at version 3 for > the client and the server and then restarted the NFS server SMF > service, the nfsmapid daemon was still probing DNS for the > _nfsv4idmapdomain TXT record. I found this odd. (My /etc/default/ > nfs file has the NFSMAPID_DOMAIN variable commented out - not sure if > this stops nfsmapid from probing DNS or not but this isn't the point > of my question). I disabled the nfsmapid SMF service and tried > again. The DNS probes no longer occurred and my Mac continued to > mount NFS mounts points fine.
If you have the nfs/mapid service enabled, it will try to make sure it can provide the service. I understand that you have set the maximum NFS version to 3, but that's not something that we have mapid check for, because you could still do a manual mount and specify "-o vers=4" and need mapid to be there. You were right to disable mapid to stop the DNS query; you could also have explicitly set a domain in /etc/default/nfs to stop the DNS queries. Of course, I would not have expected that DNS query to have been a problem, either (more below). > Actually technically speaking a Mac client only supports up to NFS > version 3 currently (I'm running OS X 10.4.9) so even if I hadn't > tuned /etc/default/nfs to max out at version 3 it would still seem > logical that nfsmapid shouldn't be doing anything when I attempt > NFSv3 mounts. I wouldn't expect mapid to be involved if you're doing manual NFSv3 mounts. I would expect that you would not see mounts occur out of /etc/vfstab until the mapid service was up and running, since those mounts are associated with the nfs/client service and there is an SMF dependency on mapid unless mapid is disabled. Did you observe what felt like a slowdown in manual mounts before you disabled mapid, or would the /etc/vfstab thing explain it? Rob T
