Subject: Re: [nfsv4] Validation of migrated clientids

From: Spencer Shepler <[email-masked]>
Date: Fri, 17 Mar 2006 16:41:54 -0600

I have created the following issue:

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue6

To track resolution of this item.

On Fri, William A.(Andy) Adamson wrote:
> I brought this issue up during the last NFSv4.1 - minor version document 
> review conference call.
> 
> Given an NFSv4.0 exported cluster file system, we want to use migration to 
> load balance clients across the parallel NFSv4.0 servers.
> 
> NFSv4.0 servers exporting a cluster file system all see the same data, ACLs 
> and file handles. We want to follow section 8.14.1 and migrate a clients state 
> from the old server to the new server, avoiding any lock recovery by the 
> client and grace period by the exported cluster.
> 
> rfc3530 section 8.14.1 states: 
> 
>     "if the servers are successful in
>     transferring all state, the client will continue to use stateids
>     assigned by the original server.  Therefore the new server must
>     recognize these stateids as valid.  This holds true for the clientid 
>     as well."
> 
> During a migration event, the old server will transfer the nfs_client_id4 
> structure with verifier and id, the unique 64bit clientid, and the setclientid 
> principal to the new server.
> 
> Say the new server checks it's cache of existing nfs_client_id4 and associated 
> 64bit clientids and finds no conflicts with the migrated nfs_client_id4 and 
> 64bit clientid (e.g. all unique on new server), so the new server is ready to 
> service the migrated client.
> 
> In NFSv4.0, this results in two concerns:
> 
> First, the client knows that a file system has migrated - but as Trond points 
> out, how does the client know if the state has also migrated?
> 
> I suggested sending a RENEW to the new server. Tronds concern is that NFS4_OK 
> on the RENEW return doesn't guarentee that the 64bit clientid sent by the 
> migrated client is associated with the client's migrated state on the new 
> server - it could be that the 64bit clientid just happens to represent a 
> different client's state.
> 
> Is there any solution to this problem in NFSv4.0? Any suggestions for NFSv4.1? 
> 
> Second, if the migrated client reboots and therefore negotiates a new 
> clientid, the (new) server will not be able to associate the new 
> nfs_client_id4 id field with the old migrated nfs_client_id4 field due to the 
> use of server ip addresses.  Instead of immediately releasing all state 
> associated with the old instance of the client, the (new) server will be 
> forced to wait the lease period ends.
> 
> This is not so bad.
> 
> Any other consequences that I missed?
> 
> Thanks
> 
> -->Andy
> 
> 
> 
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Sun, 19 Mar 2006 19:58:53 -0800 (PST)

> > Is there any solution to this problem in NFSv4.0? Any suggestions for NFSv4.1? 

I had proposed two error codes to indicate to the client whether state had moved
or not, ( see http://www1.ietf.org/mail-archive/web/nfsv4/current/msg02576.html )
but Dave Noveck said later in this thread that fs_location_info had another way.
I don't have any preference.