[nfsv4] Validation of migrated clientids

["William A.(Andy) Adamson" <andros at citi.umich.edu>]

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
nfsv4 at ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4