Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     linux-nfs@vger.kernel.org
From:   guy keren <guy@vastdata.com>
Subject: questions about the linux NFS 4.1 client and persistent sessions
Message-ID: <02b2121f-42d1-2587-6705-ca2aadb521bc@vastdata.com>
Date:   Sat, 10 Oct 2020 23:39:30 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Precedence: bulk


hi,


my name is guy keren, and the company i work at is looking at 
implementing an NFS 4.1 server for our existing storage product.


during the design, we encountered some issues with high-availability and 
persistent sessions handling by the linux NFS client, and i would like 
to understand a few things about the linux NFS client - i read all 
relevant material on www.linux-nfs.org, and spent a while reading the 
relevant recovery code in the nfs4.1 client kernel sources, but i am 
missing some things (a pointer to the relevant part in the recovery code 
will be appreciated as well):


1. suppose there is a persistent session that got disconnected (because 
of a server restart, for example). i see that the client is re-sending 
all the in-flight commands as part of

     the recovery. however, suppose that one of the commands was a 
compound command containing 2 requests, and the reply to the first of 
them was NFS4_OK, and to the 2nd it was NFS4ERR_DELAY - will the 
client's code know that after it finishes recovery of the session - then 
when it creates a new session, it needs to re-send the 2nd request in 
this compound command? the broader question is about a compound with N 
commands, where the first X have an NFS4_OK reply and the last N-X have 
NFS4_DELAY - will the client re-send a new compound with the last N-X 
commands after establishing a new session?


2. if there is a non-persistent session, on which the client sent a 
non-idempotent request (e.g. rename of a file into a different 
directory), and the server restarted before the client received the 
response - will the client just blindly re-send the same request again 
after establishing a new session, or will it take some measures to 
attempt to understand whether the command was already executed? i.e. if 
the server already executed the rename, then re-sending it will return a 
failure to locate the source file handle (because it moved to a new 
directory). does the linux NFS client attempt to recover from this, or 
will it simply return an error to the application layer?


3. what NFS server with persistent sessions is used (or was used) when 
testing the persistent sessions support in the linux NFS client? the 
linux NFS server, as far as i understood, cannot support persistent 
sessions (due to lack of assured persistent memory).


thanks in advance,

--guy keren

Vast data.