On Thu, 2012-04-26 at 14:43 -0400, Chuck Lever wrote:
> On Apr 26, 2012, at 12:55 PM, Myklebust, Trond wrote:
>
> > On Thu, 2012-04-26 at 12:24 -0400, Chuck Lever wrote:
> >> On Apr 23, 2012, at 4:55 PM, Chuck Lever wrote:
> > Then lets move the flavour out of the clientid string,
>
> Removing the flavor from the nfs_client_id4 string makes sense.
>
> > and just settle
> > for handling CLID_INUSE by changing the flavour on the SETCLIENTID call.
>
> This is where I get hazy.
>
> If I simply change the authentication flavor on the existing clp->cl_rpcclient, will this affect ongoing RENEW operations that also use this transport? Do we want subsequent RENEW operations to use the new flavor?
>
> Thinking hypothetically, it seems to me that CLID_INUSE is really an indication of a permanent configuration error, or a software bug, and we should not bother to recover. But maybe that's my limited imagination. Under what use cases do you think CLID_INUSE might occur and it might be useful to attempt recovery?
>
The server caches the principal name that was used to call SETCLIENTID
when the lease was established. Any attempt to call SETCLIENTID with a
different principal will result in CLID_INUSE unless the lease has
expired.
So what I was proposing wasn't that you try to change the authentication
flavour on an existing nfs_client. It was that when you are probing, you
can use the CLID_INUSE reply from SETCLIENTID as a direct indication
that the server is indeed trunked, and that you already hold a lease on
that server, but that the authentication flavour that you are trying to
use is wrong.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
