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;
MIME-Version: 1.0
References: <061a976c-2082-bb86-91ec-f0f97a73e1ac@vastdata.com>
In-Reply-To: <061a976c-2082-bb86-91ec-f0f97a73e1ac@vastdata.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Tue, 20 Apr 2021 19:28:36 -0400
Message-ID: <CAN-5tyHb8CXVTnZuODJAKs+0QZy53dSJk0nKZPNeAhJ-CVQYZg@mail.gmail.com>
Subject: Re: Linux NFS4.1 client's "server trunking" seems to do the opposite
 of what the name implies
To:     guy keren <guy@vastdata.com>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Apr 20, 2021 at 4:59 PM guy keren <guy@vastdata.com> wrote:
>
>
> 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).

Hi Guy,

Current implementation of the linux client does not support session
trunking to the MDS (nor does it support client id trunking). I'm
hoping session trunking support comes in the near future. Clientid
trunking might not be something that's supported unless we'll have a
clustered NFS server out there that can utilize that behaviour.

Btw you can do multipath NFS flows by using the combination of
nconnect and the newly proposed sysfs interface (still in review) that
can manipulate server endpoints.


>
> thanks,
>
> --guy keren
>
> Vast Data.
>