public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: guy keren <guy@vastdata.com>
To: linux-nfs@vger.kernel.org
Subject: questions about the linux NFS 4.1 client and persistent sessions
Date: Sat, 10 Oct 2020 23:39:30 +0300	[thread overview]
Message-ID: <02b2121f-42d1-2587-6705-ca2aadb521bc@vastdata.com> (raw)


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.


             reply	other threads:[~2020-10-10 22:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-10 20:39 guy keren [this message]
2020-10-14 19:26 ` questions about the linux NFS 4.1 client and persistent sessions J. Bruce Fields
2020-10-17 20:40   ` Guy Keren
2020-10-17 21:14     ` J. Bruce Fields
2020-10-18 11:18       ` Guy Keren
2020-10-19 18:14         ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02b2121f-42d1-2587-6705-ca2aadb521bc@vastdata.com \
    --to=guy@vastdata.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox