From: cburnett@us.ibm.com
Date: 07/24/02-02:07:52 PM Z
From: cburnett@us.ibm.com
Subject: Re: SETCLIENTID issues (long)
Message-ID: <OF293DC373.262DCDA0-ON85256C00.0063E967@us.ibm.com>
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 cburnett@us.ibm.com)
Mike Eisler
<mike@eisler.com> To: Carl Burnett/Austin/IBM@IBMUS
cc: nfsv4-wg@sunroof.eng.sun.com
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.
cburnett@us.ibm.com 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:05 AM Z CST