linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).