Hi Marc- On Jun 27, 2013, at 2:42 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2013-06-27 at 11:13 -0700, Marc Eshel wrote: >> >> "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote on 06/27/2013 >> 11:05:44 AM: >> >>> From: "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> >>> To: Marc Eshel/Almaden/IBM@IBMUS, >>> Cc: "linux-nfs@xxxxxxxxxxxxxxx" <linux-nfs@xxxxxxxxxxxxxxx>, "J. >>> Bruce Fields" <bfields@xxxxxxxxxx>, "Adam C. Emerson" >>> <aemerson@xxxxxxxxxxxx>, "Matt W. Benjamin" <matt@xxxxxxxxxxxx> >>> 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... >> >> How is the client detecting that it is the same server? I use a > > See section 2.10.5.1 of RFC5661. > >> different IP address on the mount command. Why is the client not >> handling NFS4ERR_CLID_INUSE? Is there a section of the spec that prescribes how the client should recover from NFS4ERR_CLID_INUSE? I believe this is not an error that can be recovered from. The cases where a clientid is being spoofed are not easily distinguished from cases where it might be safe for a client to try a different client ID string. However, note that NFSv4.1 takes a Uniform Client String approach: an NFSv4.1 client unconditionally uses the same nfs_client_id4.id string and boot verifier for all servers. An important reason for this is that if Transparent State Migration occurs, a destination server must be able to recognize the client when it connects expecting its state to be available. > We only recently changed the client to always use krb5i (or fallback to > AUTH_SYS if krb5i is not available) for EXCHANGE_ID. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
