Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     linux-nfs@vger.kernel.org
From:   guy keren <guy@vastdata.com>
Subject: Linux NFS4.1 client's "server trunking" seems to do the opposite of
 what the name implies
Message-ID: <061a976c-2082-bb86-91ec-f0f97a73e1ac@vastdata.com>
Date:   Tue, 20 Apr 2021 23:59:16 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Precedence: bulk


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.