From: Chuck Lever <chuck.lever@oracle.com>
To: Neil Brown <neilb@suse.de>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Legacy NFS client DNS resolver fails since 2.6.37
Date: Sun, 28 Oct 2012 21:03:45 -0400 [thread overview]
Message-ID: <6F448C67-E729-41E7-A09C-A49D15B50D5E@oracle.com> (raw)
Hi Neil-
To use the legacy DNS resolver for resolving hostnames in NFSv4 referrals, I've installed the /sbin/nfs_cache_getent script on my NFS client "degas." I've confirmed it works with a 2.6.36 kernel.
However, since 2.6.37 commit c5b29f885afe890f953f7f23424045cdad31d3e4 "sunrpc: use seconds since boot in expiry cache" the legacy DNS resolver appears not to work. When attempting to follow a referral that uses a server hostname, the client fails 100% of the time to mount the referred to server with an error such as:
[cel@degas example.net]$ ls home
ls: cannot open directory home: No such file or directory
The contents of the dns_resolve cache appear to indicate that there are resolution results in the cache, but the CACHE_VALID flag is not set for that entry:
[root@degas dns_resolve]# cat content
# ip address hostname ttl
# , klimt.example.net 48
klimt.example.net is the hostname that is contained in the referral.
I have a second referral called "ip-address" in the same directory (domainroot), with the same content except the IP address of klimt is used instead of its hostname. Following that second referral always works.
I've tried every stable.0 release up to 3.6.0, and the behavior is roughly the same for each, which suggests that there is no upstream fix for this issue thus far.
Since I've never seen a problem like this reported, I'm wondering if anyone else can confirm this issue.
I have a narrow interest in fixing the legacy DNS server in stable kernels, but there may also be a latent problem with the RPC cache implementation that could spell trouble for other consumers, even post-3.6.
A rough outline of how you might reproduce this:
+ Build and install a 2.6.37 or later kernel for your NFS client with CONFIG_NFS_USE_LEGACY_DNS=y.
+ Set up an NFS server with "refer=" exports. man exports(5)
+ On your client, mount the server directory that contains the exports, then try to "cd" through one of the referrals.
If you don't feel up to replicating the above arrangement, can you suggest cache debugging instrumentation that can be added to my client to help nail this? Thanks for any advice!
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
next reply other threads:[~2012-10-29 1:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 1:03 Chuck Lever [this message]
2012-10-29 1:59 ` Legacy NFS client DNS resolver fails since 2.6.37 NeilBrown
2012-10-29 17:47 ` Chuck Lever
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=6F448C67-E729-41E7-A09C-A49D15B50D5E@oracle.com \
--to=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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).