From: Neil Brown <neilb@suse.de>
To: Jason Keltz <jas@cse.yorku.ca>
Cc: linux-nfs@vger.kernel.org
Subject: Re: exporting to a list of IPs
Date: Thu, 5 Aug 2010 08:13:11 +1000 [thread overview]
Message-ID: <20100805081311.727e9185@notabene> (raw)
In-Reply-To: <4C596F81.6010409@cse.yorku.ca>
On Wed, 04 Aug 2010 09:47:45 -0400
Jason Keltz <jas@cse.yorku.ca> wrote:
> Neil Brown wrote:
> > On Tue, 03 Aug 2010 11:53:07 -0400
> > Jason Keltz <jas@cse.yorku.ca> wrote:
> >
> >> Hi.
> >>
> >> Why is it that you cannot NFS export to a list of IPs and have exportfs
> >> leave the list of IPs in etab without converting over to FQDN?
> >
> > My memory is that if you only list IP addresses in /etc/exports then it will
> > do just want you want. But if you list any host names or net groups then it
> > has to do a DNS lookup on everything to see if either of those matches.
>
> Hi Neil.
>
> Thanks for your response!
>
> Actually, if I list ONLY IPs in /etc/exports, and nothing else, then
> etab gets converted over to using hostnames:
>
> For example:
>
> # cat /etc/exports
> /test 130.63.92.24(ro,sync)
>
> # cat /var/lib/nfs/etab
> (it's empty)
> # exportfs -a
> # cat /var/lib/nfs/etab
> /test
> gold.cs.yorku.ca(ro,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2)
>
> In fact, I see two problems here. First, exportfs shouldn't convert
> etab over to using FQDN. Second, if it does do this, I don't see why
> rpc.mountd needs to RE-resolve each hostname in etab. During this
> time (right after exportfs exits), all of my NFS shares hang, and an
> strace of rpc.mountd shows that it is re-resolving all the hostnames
> from etab. When it finishes, all activity continues. On one system
> with a total of 30,000 hostnames listed, this ends up in a 30 second
> hang time for all NFS exports! I was able to shrink this time slightly
> by putting a caching name server on the NFS server, so that the NFS
> server wasn't killing the DNS, but this didn't help enough. If exportfs
> truly has to convert IPs over to hostname, I can live with that, but
> then rpc.mountd shouldn't re-resolve the names. If both can live with
> IPs, I'm good with that as well.
>
> Now, albeit, I'm using an older nfs-utils that comes with RHEL4
> installation. Compiling a later version is a bit tricky because some
> libraries have changed. That being said, reviewing the source (given
> that I don't really know it that well) for the newest nfs-utils, I don't
> see how this behavior would really be any different. For example, in
> client_lookup in support/export/client.c, adding some printfs, I can see
> that the IPs always get into the ...
>
> if (htype == MCL_FQDN && !canonical) {
> ... where there's a call to gethostbyname.
>
> This is the same in nfs-utils-1.0.6 as it is in 1.2.2.
True, but client_gettype is different.
In 1.0.6, w.x.y.z is treated as MCL_FQDN
In 1.2.2, w.x.y.z is treated as MCL_SUBNETWORK
If you use w.x.y.z/32 then it will be treated as MCL_SUBNETWORK and should do
what you want.
NeilBrown
>
> >> Why does mountd need to repeat the gethostbyname() lookup on every host
> >> even though exportfs already converted over to using hostname?
> >
> > exportfs doesn't convert over host hostnames. It essentially
> > copies /etc/exports to /var/lib/nfs/etab with minor formatting changes.
> >
> > What do you actually put in /etc/exports, what do you find
> > in /var/lib/nfs/etab, and what exactly is the problem?
> >
> > NeilBrown
>
> See above.. thanks :)
>
> Jason.
next prev parent reply other threads:[~2010-08-04 22:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 15:53 exporting to a list of IPs Jason Keltz
2010-08-04 3:45 ` Neil Brown
2010-08-04 13:47 ` Jason Keltz
2010-08-04 22:13 ` Neil Brown [this message]
2010-08-06 1:42 ` Jason Keltz
2010-08-06 4:26 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100805081311.727e9185@notabene \
--to=neilb@suse.de \
--cc=jas@cse.yorku.ca \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).