public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: guy keren <guy@vastdata.com>
To: linux-nfs@vger.kernel.org
Subject: Linux NFS4.1 client's "server trunking" seems to do the opposite of what the name implies
Date: Tue, 20 Apr 2021 23:59:16 +0300	[thread overview]
Message-ID: <061a976c-2082-bb86-91ec-f0f97a73e1ac@vastdata.com> (raw)


Hi,

when attempting to make two NFS 4.1 mounts from a linux NFS client, to 
two IP addresses belonging to two different hosts in the same cluster 
(i.e. the server major id in the EXCHANGE_ID response is the same) - the 
linux NFS4.1 client discards the new TCP connection (to the 2nd IP) and 
instead decides to use the first client connection for both mounts. this 
seems to be handled in a hard-coded inside the function named 
"nfs41_discover_server_trunking", and leads to reduced performance, 
relative to using NFS3 (which will use two different TCP connections to 
the two different hosts in the storage cluster).

i was under the impression that (client_id) trunking is supposed to 
allow to multiplex commands over multiple TCP connections - not to 
consolidate different workloads onto the same TCP connection.

is there a way to avoid this behaviour, other then faking that the 
"server major id" is different on each node in the cluster? (this is 
what appears to be done by NetApp, for instance).

thanks,

--guy keren

Vast Data.


             reply	other threads:[~2021-04-20 20:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20 20:59 guy keren [this message]
2021-04-20 23:28 ` Linux NFS4.1 client's "server trunking" seems to do the opposite of what the name implies Olga Kornievskaia
     [not found]   ` <4999b214-db58-a5ab-3097-523cf9a51c75@vastdata.com>
2021-04-21 13:21     ` Olga Kornievskaia
2021-04-21  7:42 ` guy keren
2021-04-21 12:18   ` Trond Myklebust

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=061a976c-2082-bb86-91ec-f0f97a73e1ac@vastdata.com \
    --to=guy@vastdata.com \
    --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