On Jul 3, 2007, at 8:40 AM, Robert Thurlow wrote:
> 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?
>
I was noticing a slow down in the Mac mounting up mount point. The
largest contributor was DNS PTR lookups as my /etc/nsswitch.conf file
"files dns" for hosts and ipnodes. I saw this via snoop and that's
when I saw the DNS TXT probes for the NFSv4 domain name ... well, I
learned this after Googling for _nfsv4idmapdomain and reading the
most excellent OpenSolaris article on the nfsmapid daemon. That's
when the question came up in my mind about why is any part of NFSv4
involved with NFSv3 mounts ... seems odd to me.
Because of the way my home network is setup right now (I don't have
an authoritative DNS server setup with a PTR domain ... yet), I can't
easily determine is the NFSv4 element is adding to the slow mounts.
Right now the main slowdown is PTR probes when a mount request comes in.
On the nfsmapid SMF dependency with the NFS server service ... I can
disable nfsmapid via SMF and the NFSv3 mounts still work but as
you've suggested there is a SMF dependency such that when I do a
restart on the NFS server (for stuff like changing /etc/default/nfs
and forcing the max version to 3) nfsmapid is restarted as well.
> Rob T
--
________________________________________________________________________
___
/\ Sean O'Neill
\\ \ Sun Microsystems, Inc.
\ \\ /
/ \/ / / 13750 US 281 North
/ / \//\ Suite 270
\//\ / / San Antonio, TX 78232
/ / /\ /
/ \\ \ Phone: (703) 485-4658
\ \\ Internal Ext: x81506
\/ Office Fax: (703) 485-4658
E-Mail: Sean.W.ONeill at Sun.COM
________________________________________________________________________
___
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
________________________________________________________________________
___
