Subject: Re: SETCLIENTID issues (long)

From: [email-masked]
Date: Wed, 24 Jul 2002 14:07:52 -0500

Mike,

Thanks for the clarification. Would it be correct to say that whenever a
server receives a SETCLIENTID_CONFIRM for a given nfs_client_id4.id value
(x in the below example), that it can (and should) reclaim existing locking
state (probably delegations too??) for the nfs_clientid4.id (x). It can
also reclaim any resources for previous server assigned clientid4 instances
of the nfs_client_id4.id value x. In the below example, {u, x, c } since
{v, x, d} is now the active record for the client.

If this is true, then having it stated very specifically in the RFC would
be good. Maybe I just need to read the existing text again more closely.

Thanks,
Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

                      Mike Eisler                                                                                                             
                      <[email-masked]>        To:       Carl Burnett/Austin/IBM@IBMUS                                                        
                                               cc:       [email-masked]                                                         
                      07/24/2002 12:46         Subject:  Re: SETCLIENTID issues (long)                                                        
                      PM                                                                                                                      
                      Please respond to                                                                                                       
                      mike                                                                                                                    

Apologies for not responding sooner. I've been
having problem integrating my email setup with my vpn
setup.

[email-masked] wrote:

>
>
> ** On July 8, Rick asks
>
> > > How is the server supposed to distinguish between a client
> > > doing a retry of setclientid and different clients doing
> >
> > Let x be the "id" field of the nfs_client_id4 struct,
> > v be the verifier, and c be the clientid4 value.
> >
> > A client that does a retry of a SETCLIENTID { v, x }
> > gets the following result depending on the following cases:
> >
> .
> .
> .
> .
> >
> > - DRC miss and server has recorded a confirmed { u, x, c }
> > such that v != u and has not recorded any unconfirmed
> > { *, x, * } record for x. The server records an
> > unconfirmed { v, x, d } (d != c). The server awaits
> > confirmation of d via SETCLIENTID_CONFIRM.
> >
>
> Is this really true given x (the nfs_client_id4.id value)
> is the same? I thought this case represents a rebooted client
> with a new verifier (assuming auth is the same). Isn't the

What has probably happenned in this scenario is that the client
has rebooted and issued an RPC SETCLIENTID { v, x }
which did not make it to the server. The client then retries.
What ha spossibly happenned is the Byzantine router scenario
that replays an old RPC request. My description deals with
either scenaro.

The server has recorded verifier u for client id string x, with
clientid4 c.. The client has sent verifier
v for the same client id string x. It is indeed a possibly rebooted client.
Or it might be the Byzantine router scenario.

What may not have been clear is that the server always responds to
to a SETCLIENTID. Thye question is what to respond with,
c or d. It is d in this case.

 > server supposed to return clientid4 c so the following

No, the server has to return clientid4 d.

>
> SETCLIENTID_CONFIRM call causes the server to release the
> state for the previous life of x. If the server creates
> a new record with clientid4 d, what is going to reclaim the
> record and associated state for {u, x, c}? Where did I get
> confused?

If the client truly wants to establish a new clientid4 and
thereby delete all the state associated with clientid4 c,
then it must follow up with a SETCLIENTID_CONFIRM { d }.

>
> > That said, there will inevitably be NFS4ERR_CLID_INUSE
> > errors reported whether due to server or client bugs, or the
> > improbable occurring. As Spencer wrote on July 18, the
> > client that has done its level best to pick a collision
> > free id string that still gets NFS4ERR_CLID_INUSE can use
> > this algorithm: "have it [the client] wait a server lease
> > period and retry the operation". I would add, that if the
> > client still gets NFS4ERR_CLID_INUSE, we can assume that
> > another client has usurped the id string. This is why
> > the SETCLIENTID4 results look like this:
> >
> > union SETCLIENTID4res switch (nfsstat4 status) {
> > case NFS4_OK:
> > SETCLIENTID4resok resok4;
> > case NFS4ERR_CLID_INUSE:
> > clientaddr4 client_using;
> > default:
> > void;
> > };
> >
> > The client that gets an NFS4ERR_CLID_INUSE after waiting
> > the lease period should log the offending client's
> > address. Such a client might also check whether the
> > offending address is one that of the client getting the
> > NFS4ERR_CLID_INUSE error.
> >
>
> Would it also be acceptable for the client to then retry
> the SETCLIENTID with a newly generated nfs_client_id4.id
> value after it has logged a message and evaluated the
> client_using information

Certainly. But then the onus is on the client to implement a way to
generate the
same nfs_client_id4.id string when it reboots. There's no requirement in
the
NFSv4 specification for clients to record their generated nfs_client_id4.id
string into stable storage (for example the client may not have any local
stable storage ... it might be a diskless and getting its root partition
from the
same NFSv4 server it is doing SETCLIENTID to).
    -mre

---

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Jul 2002 13:12:30 -0700

Let me give a context free answer.

A server that receives a SETCLIENTID_CONFIRM called with a
clientid4 of { c } MUST delete the client's (as identified
by nfs_client_id4.id) state (locks, share reservations,
and delegations) on the server if and only if all the
following are true:

- duplicate requested cache miss

- server has recorded an unconfirmed clientid { *, *, c }
  where the second asterisk is any nfs_client_id4.id
  value, and the first asterisk is any SETCLIENTID
  verifier.

- principal of SETCLIENTID_CONFIRM matches that used
  with the SETCLIENTID that casued the server to record
  the unconfirmed { *, *, c }

- This is crucial: server has not recorded a confirmed {
  *, *, c }

The corollary is that for any SETCLIENTID_CONFIRM { c },
if there is a recorded, confirmed { v, x, c }, then the
server MUST NOT delete the aforementioned state for the
client identified by nfs_client_id4.id { x }.

 > If this is true, then having it stated very specifically
 > in the RFC would be good. Maybe I just need to read the
 > existing text again more closely.

Agreed.

The specification does mention in one or more places that
SETCLIENTID_CONFIRM deletes the state. However, given
the issues of how to update callback information without
removing state, the specification needs some re-work.
The specification needs to be very clear on
SETCLIENTID/SETCLIENTID_CONFIRM semantics since those two
operations are the basis of NFSv4's state management.