Subject: RE: [nfsv4] Validation of migrated clientids

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 19 Mar 2006 11:02:45 -0500

As far as the first of these concerns, I believe that fs_location_info,
as proposed would address this in v4.1.

>    o    The same-state mask indicates, in combination with the
>          appropriate location ids, whether two replicas will have the
>          same state environment.  This does not necessarily mean that
>          when performing migration, the client will not have to reclaim
>          state.  However it does mean that the client may proceed using
>          his current clientid just as if there were no migration event
>          and only reclaim state when an NFS4ERR_STALE_CLIENTID or
>          NFS4ERR_STALE_STATEID error is received.

Where the same-state mask indicates no possibility of state sharing the
client would know that use and checking of an existing clientid would
not be supported, and so you would avoid the possiblity of inadvertantly
running into valid stateid by accident.  

I don't quite understand the second issue, specifically the phrase
"due to the use of server ip addresses" so I'm not sure if the
fs_location_info stuff might help there as well.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Friday, March 17, 2006 5:42 PM
To: [email-masked]
Subject: Re: [nfsv4] Validation of migrated clientids

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

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sun, 19 Mar 2006 13:41:54 -0500

> running into valid stateid by accident.  

Yep, that sounds fine.

> fs_location_info stuff might help there as well.

One example: suppose a client migrates and succesfully uses its old
state with the new server, then the new server reboots.  In order for
the new server to meet the requirements of 8.6.3 ("Network Partitions
and Recovery"), it has to be able to identify the SETCLIENTID's that
come in after reboot as originating from the client that migrated to it
before the reboot.

But 8.1.1 says that the client-generated identifier presented in the
SETCLIENTID should vary depending on the IP address of the server.  So
there's no way that the new server can know the identifier that the
migrated client is going to present after reboot.

Should the client keep its old client identifier in this case?  (And how
do we make that work over client reboots?)

In general we're worried about what problems might be caused by the lack
of a way to track a client across migration events.

--b.