From: cburnett@us.ibm.com
Date: 07/19/02-12:30:24 PM Z
From: cburnett@us.ibm.com Subject: Re: still more CLID_INUSE Message-ID: <OF41B30A69.5D36F1C8-ON85256BFB.005E2EBF@us.ibm.com> Date: Fri, 19 Jul 2002 12:30:24 -0500 >>Peter wrote: >>I'm still not convinced that the current way of doing SETCLIENTID is >>optimal. But, since we have much to do, I will stop complaining about it, >>at least until 4.0 is finished :-) I would agree that SETCLIENTID has some holes that should addressed. I would prefer to see this get addressed in 4.0 instead of being deffered. Given this is the foundation upon which NFS V4 state mangement is built, it seems like it needs to be complete the first time out of the chute. Independent of when it is handled, shouldn't an item be added to the NFS issues list for this? Here is my attempt to capture what I think are the main issues. I hoped I have included the original problem Rick reported. SETCLIENTID does not handle the case of two clients independently generating the same nfs_client_id4.id value. While the spec encourages implementations to create unique values, the potential exists in the absence of an RFC dictated algorithm. Unless servers further qualify the client's signature with additional SETCLIENTID information such as the RPC authentication and/or client network information (callback info, reverse binding), the potential for indefinite CLID_INUSE errors exists. The RPC authentication is probably not a good choice as a distinguishing client property. Some environments will use the same credential across all the clients to avoid the creation of per client principals and the associated administrative overhead. In fact I would guess that AUTH_SYS (UID=0) will be the predominant choice. If the server chooses to use client network information as a distinguishing feature, then support for multiple callback paths to a client with more than one network address is prohibited. This would preclude NFS implementations from supporting a desirable availability characteristic. If a client does receive repeated CLID_INUSE errors because of accidental id collision, the specification does not provide guidance on how a client might react. It seems reasonable, that a client could make a decision to generate a new id value and retry the SETCLIENTID operation after some delay period. Ideally, there is probably an opportunity to modify the SETCLIENTID "handshaking" mechanism to handle the coincidental occurrence of duplicate nfs_client_id4.id values given it is possible. Carl Carl Burnett AIX Kernel Architecture - Distributed File Systems (512) 838-8498, TL 678-8498 (please reply to cburnett@us.ibm.com) |---------+----------------------------------> | | Peter Astrand | | | <astrand@lysator.liu. | | | se> | | | Sent by: owner-nfsv4- | | | wg@sunroof.eng.sun.com | | | | | | | | | 07/19/2002 03:47 AM | | | | |---------+----------------------------------> >---------------------------------------------------------------------------------------------------------------| | | | To: nfsv4-wg@sunroof.eng.sun.com | | cc: | | Subject: Re: still more CLID_INUSE | | | | | >---------------------------------------------------------------------------------------------------------------| . . . . I'm still not convinced that the current way of doing SETCLIENTID is optimal. But, since we have much to do, I will stop complaining about it, at least until 4.0 is finished :-) -- /Peter Åstrand <astrand@lysator.liu.se>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:02 AM Z CST