MIME-Version: 1.0
References: <CA+5eE-TWSOGs+7wJnykbwD84iTuXStgmsprxbXdf27ciHMg2Ng@mail.gmail.com>
In-Reply-To: <CA+5eE-TWSOGs+7wJnykbwD84iTuXStgmsprxbXdf27ciHMg2Ng@mail.gmail.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Wed, 20 Mar 2019 10:28:51 -0400
Message-ID: <CAN-5tyHO0mJfwha2z1+bFcq6+R3E1qws2p_EYJZbm93BRaS=EQ@mail.gmail.com>
Subject: Re: Some questions about Trunking
To:     Marvin Zhang <fanzier@gmail.com>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

This question is more of an NFSv4.1 protocol question thus I would
encourage you to ask it on the nfsv4@ietf.org.

On Tue, Mar 19, 2019 at 11:06 PM Marvin Zhang <fanzier@gmail.com> wrote:
>
> Hi Experts,
> Here are some questions about trunking:
> 1.  For session trunking. During first mount(or first connection),
> client create a session. During the second mount(or second
> connection), client will reuse the session which the first connection
> created. Does the second mount create a new super block or reuse the
> previous?
> If there is a READ request on this session, how to judge to
> use which connection?

Session trunking does not require the client to create a different
mount in your example. A single mount could have multiple TCP
connections established between a client and a server and they would
use the same NFSv4.1 session to send operations to the server. A read
operation issued by the application using the NFS mount could use one
of those connection and the question which one it would use is
protocol implementation specific. Simplest implementation round robins
connections for incoming RPC tasks.

If the client mounted a server and then decides to mount the same
server again (given same mount options and credentials), in the linux
implementation, the existing NFS client (and its TCP connection) would
be re-used. Thus it would not be a case of session trunking.

> 2. For client id truking. As protocol said, client can create multipl
> session at the same time. I can't understand in which scenario client
> can create multiple session

Again IETF list can provide some examples and motivations for the
clientid case. I think perhaps it was for the clustered server
environment where the client would use the same client id across
different cluster nodes but it would establish unique sessions to the
nodes.