On Wed, Mar 20, 2019 at 10:29 PM Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > This question is more of an NFSv4.1 protocol question thus I would > encourage you to ask it on the nfsv4@xxxxxxxx. > > On Tue, Mar 19, 2019 at 11:06 PM Marvin Zhang <fanzier@xxxxxxxxx> 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. I just followed this article: https://packetpushers.net/multipathing-nfs4-1-kvm/ . In this article, client mounts the server twice in differ conections. But as you said, it's not session trunking. I still don't konw how to mount a server only once with two connection. Could you give me a sample here? I don't find any example in google searching result. > > 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.
