From: "Aurélien Aptel" <aaptel@suse.com>
To: Chuck Lever <chuck.lever@oracle.com>,
David Howells <dhowells@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
linux-cifs@vger.kernel.org, linux-afs@lists.infradead.org,
ceph-devel@vger.kernel.org, keyrings@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: What's a good default TTL for DNS keys in the kernel
Date: Fri, 17 Apr 2020 13:31:39 +0200 [thread overview]
Message-ID: <87sgh22vs4.fsf@suse.com> (raw)
In-Reply-To: <8DC44895-E904-4155-B7B8-B109A777F23C@oracle.com>
Chuck Lever <chuck.lever@oracle.com> writes:
> The Linux NFS client won't connect to a new server when the server's
> DNS information changes. A fresh mount operation would be needed for
> the client to recognize and make use of it.
>
> There are mechanisms in the NFSv4 protocol to collect server IP addresses
> from the server itself (fs_locations) and then try those locations if the
> current server fails to respond. But currently that is not implemented in
> Linux (and servers would need to be ready to provide that kind of update).
We have a very similar system in CIFS. Failover can be handled in 2 ways
(technically both can be used at the same time):
a) with DFS, the mount can have a list of possible location to connect
to, sort of like cross-server symlinks with multiple possible
targets. Note that the target value uses hostnames.
b) the domain controler can notice the server is down and automatically
switch the server hostname DNS entry to a backup one with a different IP.
>> CIFS also doesn't make direct use of the TTL, and again this may be because it
>> uses the server address as part of the primary key for the superblock (see
>> cifs_match_super()).
When we try to reconnect after a failure (using (a) or just reconnecting
to same server) we resolve the host again to try to use any new IP (in
case (b) happened). This is done via upcalling using the request_key()
API.
The cifs.upcall prog (from cifs-utils) calls getaddrinfo() and sets a
key with a default TTL of 10mn [2][3] but if the system uses DNS caching
via nscd[1] there's no way to tell how long the old IP will remain in
use...
1: https://linux.die.net/man/8/nscd
2: https://github.com/piastry/cifs-utils/blob/9a8c21ad9e4510a83a3a41f7a04f763a4fe9ec09/cifs.upcall.c#L66
3: https://github.com/piastry/cifs-utils/blob/9a8c21ad9e4510a83a3a41f7a04f763a4fe9ec09/cifs.upcall.c#L783
Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
next prev parent reply other threads:[~2020-04-17 11:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 14:20 What's a good default TTL for DNS keys in the kernel David Howells
2020-04-14 20:16 ` Jeff Layton
2020-04-15 17:07 ` Steve French
2020-04-16 10:15 ` David Howells
2020-04-15 9:44 ` Florian Weimer
2020-04-16 10:27 ` David Howells
2020-04-16 10:33 ` Florian Weimer
2020-04-16 13:01 ` David Howells
2020-04-16 13:40 ` Chuck Lever
2020-04-17 11:31 ` Aurélien Aptel [this message]
2020-04-17 23:23 ` Steve French
2020-04-18 18:10 ` Florian Weimer
2020-04-19 4:53 ` Steve French
2020-04-19 8:37 ` David Howells
2020-04-20 0:58 ` Paulo Alcantara
2020-04-20 13:13 ` David Howells
2020-04-20 18:21 ` Paulo Alcantara
2020-04-20 22:14 ` cifs - Race between IP address change and sget()? David Howells
2020-04-20 22:30 ` Jeff Layton
2020-04-21 1:29 ` Ronnie Sahlberg
2020-04-21 2:26 ` Steve French
2020-04-21 2:29 ` Steve French
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=87sgh22vs4.fsf@suse.com \
--to=aaptel@suse.com \
--cc=ceph-devel@vger.kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dhowells@redhat.com \
--cc=fweimer@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@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).