Hi,
Keeping this simple, the controlling section of RFC 5661 is 2.10.5 (trunking).
If CLIENT presents the same eia_clientowner in two EXCHANGE_ID invocations
to "the same NFSv4.1 server" over two connections of differing network
address, 2.10.5 actually states that the server MUST return the same
value for eir_serverowner. By our choice of the same server owner, we are
consenting to clientid trunking.
It doesn't seem like anything stops one instance of Ganesha from presenting itself
as two or more completely distinct NFSv4.1 servers in response to connections of
differing address. They could share the same server scope (e.g., filehandle namespaces),
but they CANNOT share the same server owner, and consequently, they can't share
any state. (So we think it would confuse the client if we return CLID_INUSE
on the second EXCHANGE_ID.)
Matt and Adam
----- "Marc Eshel" <[email protected]> wrote:
> If it was not clear I am talking about the exchange id operation.
> Marc.
>
>
>
> From: "Myklebust, Trond" <[email protected]>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: "[email protected]" <[email protected]>, "J. Bruce
> Fields" <[email protected]>, "Adam C. Emerson"
> <[email protected]>, "Matt W. Benjamin" <[email protected]>
> Date: 06/27/2013 11:09 AM
> Subject: Re: NFSv4.1 session
>
>
>
>
> On Thu, 2013-06-27 at 11:00 -0700, Marc Eshel wrote:
> > Hi Trond,
> >
> > I am not able to mount from Linux NFS client to the same Ganesha NFS
> > server using multiple IP address. The client was providing the same
> > client-id so the server was using the same session. I tried to
> return
> > NFS4ERR_CLID_INUSE on the second mount if the target IP is different
> > but the client still did not provide a different client-id like it
> > should. I am not trying to use trunking I what to have different
> > server instance for each IP address so I can move that IP between
> > nodes in the cluster. Any ideas how to accomplish it.
> >
> > Thanks, Marc.
>
> I don't understand. The client is performing exactly as per design: it
> detects the fact that you are talking to the same server, and so it
> reuses the same client and session. This is the only sane semantic for
> a
> NFS client...
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> [email protected]
> http://www.netapp.com
--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
"Matt W. Benjamin" <[email protected]> wrote on 06/27/2013 12:41:09 PM:
> From: "Matt W. Benjamin" <[email protected]>
> To: Marc Eshel/Almaden/IBM@IBMUS,
> Cc: "Adam C. Emerson" <[email protected]>, "J. Bruce Fields"
> <[email protected]>, [email protected], Trond Myklebust
> <[email protected]>
> Date: 06/27/2013 12:41 PM
> Subject: Re: NFSv4.1 session
>
> Hi,
>
> Keeping this simple, the controlling section of RFC 5661 is 2.10.5
(trunking).
>
> If CLIENT presents the same eia_clientowner in two EXCHANGE_ID
invocations
> to "the same NFSv4.1 server" over two connections of differing network
> address, 2.10.5 actually states that the server MUST return the same
> value for eir_serverowner. By our choice of the same server owner, we
are
> consenting to clientid trunking.
>
> It doesn't seem like anything stops one instance of Ganesha from
> presenting itself
> as two or more completely distinct NFSv4.1 servers in response to
> connections of
> differing address. They could share the same server scope (e.g.,
> filehandle namespaces),
Maybe we can do that but Ganesha will have to change from identifying
clients only based on the client-id to combination of client-id and server
instance.
Marc.
> but they CANNOT share the same server owner, and consequently, they
> can't share
> any state. (So we think it would confuse the client if we return
CLID_INUSE
> on the second EXCHANGE_ID.)
>
> Matt and Adam
>
> ----- "Marc Eshel" <[email protected]> wrote:
>
> > If it was not clear I am talking about the exchange id operation.
> > Marc.
> >
> >
> >
> > From: "Myklebust, Trond" <[email protected]>
> > To: Marc Eshel/Almaden/IBM@IBMUS,
> > Cc: "[email protected]" <[email protected]>, "J. Bruce
> > Fields" <[email protected]>, "Adam C. Emerson"
> > <[email protected]>, "Matt W. Benjamin" <[email protected]>
> > Date: 06/27/2013 11:09 AM
> > Subject: Re: NFSv4.1 session
> >
> >
> >
> >
> > On Thu, 2013-06-27 at 11:00 -0700, Marc Eshel wrote:
> > > Hi Trond,
> > >
> > > I am not able to mount from Linux NFS client to the same Ganesha NFS
> > > server using multiple IP address. The client was providing the same
> > > client-id so the server was using the same session. I tried to
> > return
> > > NFS4ERR_CLID_INUSE on the second mount if the target IP is different
> > > but the client still did not provide a different client-id like it
> > > should. I am not trying to use trunking I what to have different
> > > server instance for each IP address so I can move that IP between
> > > nodes in the cluster. Any ideas how to accomplish it.
> > >
> > > Thanks, Marc.
> >
> > I don't understand. The client is performing exactly as per design: it
> > detects the fact that you are talking to the same server, and so it
> > reuses the same client and session. This is the only sane semantic for
> > a
> > NFS client...
> >
> > --
> > Trond Myklebust
> > Linux NFS client maintainer
> >
> > NetApp
> > [email protected]
> > http://www.netapp.com
>
> --
> Matt Benjamin
> The Linux Box
> 206 South Fifth Ave. Suite 150
> Ann Arbor, MI 48104
>
> http://linuxbox.com
>
> tel. 734-761-4689
> fax. 734-769-8938
> cel. 734-216-5309
>