From: cburnett@us.ibm.com
Date: 07/18/02-03:28:45 PM Z
From: cburnett@us.ibm.com
Subject: Re: yet more CLID_INUSE
Message-ID: <OF5A9E310D.28AE7B45-ON85256BFA.006E047C@us.ibm.com>
Date: Thu, 18 Jul 2002 15:28:45 -0500
So it sounds like the verifier must also be treated as a special type of
attribute indicating the "boot instance" if a given client ID. Is it really
assumed, or required that a new client instance will generate the same id?
I guess my assumption was that a completely new id could be generated on a
client restart. Perhaps the server recovery is affected by that, or at
least the timeliness of it. For locks, the server would have to hold the
granting of new locks on the affected files until the state could be
cleared on the existing locks (by lease expiration). This is where
callbacks (they could be optional) in the locking protocol could help out.
Not only would the callbacks permit decent locking performance under high
contention, but they could also allow prompt server purge of state.
Wouldn't my suggested extension address your circular problem by the fact
that once the server assigns a clientid to the first client, it can easily
recognize that the SETCLIENTID from the second client is truly a
nfs_client_id4 collision (NFSERR_CLID_INUSE). The implication of this is
that the second client must form a new nfs_client_id4 in response to the
NFSERR_CLID_INUSE if it wants to make forward progress. What am I missing?
Thanks,
Carl
Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)
rick@snowhite.cis.
uoguelph.ca To: nfsv4-wg@sunroof.eng.sun.com
Sent by: owner-nfsv4- cc:
wg@sunroof.eng.sun.com Subject: yet more CLID_INUSE
07/18/2002 02:58 PM
Carl Burnett wrote:
> The callback information should be thought of as an attribute of the
> client, not part of its unique signature. The unique signature should
best
> be limited to the nfs_client_id4 information (verifier and id). This is
Yep, I just heard that the callback info will change on a Solaris client
when it reboots, so using it seems to be out.
The problem is, if you only use the nfs_client_id4, I don't see how the
server can distinguish between a:
Client reboot - same "id", different "verifier"
2 Misconfigured Clients - same "id", different "verifier"
Therefore, it can either always return NFSERR_CLID_INUSE or never return
NFSERR_CLID_INUSE? (Which is right back where I started:-)
[stuff snipped]
> If one is willing to augment the NFS protocol structures a little, some
> improvement could perhaps be achieved. The SETCLIENTID4args could have
> a new clientid4 member added. When a client issues a new SETCLIENTID call
> for a server, it sends a clientid4 value of 0 indicating it does not yet
> have a server assigned client id. This tells the server to
I don't think this would help in this case, since I am assuming the
SETCLIENTID is being done just after a startup and does not yet have a
clientid4 shorthand. (As I understand the protocol, the only time a client
would need to do another SETCLIENTID after it has a clientid4 is when the
server has chosen to "forget the clientid4" for some reason.)
In other words, the case I am worried about would always have a clientid4
equal 0.
Any more ideas? rick
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:59 AM Z CST