Re: [PATCH RFC v18 02/11] NFSD: Add courtesy client state, macro and spinlock to support courteous server

[dai.ngo@oracle.com]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]


On 3/29/22 5:12 PM, J. Bruce Fields wrote:
> On Tue, Mar 29, 2022 at 02:45:28PM -0700, dai.ngo@oracle.com wrote:
>> This does not prevent the courtesy client from doing trunking in all
>> cases. It is only prevent the courtesy client from doing trunking without
>> first reconnect to the server.
>>
>> I think this behavior is the same as if the server does not support courtesy
>> client; the server can expire the courtesy anytime it wants. If the
>> courtesy client reconnected successfully then by the time nfsd4_create_session/
>> find_confirmed_client is called the client already becomes active
>> so the server will process the request normally.
> I'm not sure what you mean here.  All a client has to do to reconnect is
> succesfully renew its lease.

For 4.1 the client renews its lease via the SEQUENCE, either stand-alone
or in a compound. Once the SEQUENCE completes successfully then the
subsequent CREATE_SESSION is processed normally. However, if the client
did not send the SEQUENCE first then server returns BAD_SESSION for the
CREATE_SESSION request.

>    That doesn't necessarily require calling
> CREATE_SESSION again.
>
>> Also to handle cases when the courtesy client reconnects after it was in
>> EXPIRED state, we want to force the client to recover its state starting
>> with EXCHANGE_ID so we have to return BAD_SESSION on CREATE_SESSION request.
> The client should not have to send EXCHANGE_ID.

For 4.1 the expired courtesy client must send EXCHANGE_ID to reconnect
to start new session. I don't see how the *expired* courtesy client can
access the export again without sending the EXCHANGE_ID. Attached is the
pcap that shows how the courtesy client recovers once it's in
CLIENT_EXPIRED state.

-Dai

>
> --b.

[-- Attachment #2: netpart-reconnect.pcap --]
[-- Type: application/octet-stream, Size: 66396 bytes --]