All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <steved@redhat.com>
To: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: [PATCH 2/2] manpage: Add a description of the 'softreval' / 'nosoftreval' mount option
Date: Wed, 29 Jan 2020 10:47:03 -0500	[thread overview]
Message-ID: <20200129154703.6204-2-steved@redhat.com> (raw)
In-Reply-To: <20200129154703.6204-1-steved@redhat.com>

From: Trond Myklebust <trond.myklebust@hammerspace.com>

Add a description of the 'softreval' / 'nosoftreval' mount options on
the 'nfs' generic manpage.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
---
 utils/mount/nfs.man | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index 84462cd..6f79c63 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -121,6 +121,36 @@ option may mitigate some of the risks of using the
 .B soft
 option.
 .TP 1.5i
+.BR softreval " / " nosoftreval
+In cases where the NFS server is down, it may be useful to
+allow the NFS client to continue to serve up paths and
+attributes from cache after
+.B retrans
+attempts to revalidate that cache have timed out.
+This may, for instance, be helpful when trying to unmount a
+filesystem tree from a server that is permanently down.
+.IP
+It is possible to combine
+.BR softreval
+with the
+.B soft
+mount option, in which case operations that cannot be served up
+from cache will time out and return an error after
+.B retrans
+attempts. The combination with the default
+.B hard
+mount option implies those uncached operations will continue to
+retry until a response is received from the server.
+.IP
+Note: the default mount option is
+.BR nosoftreval
+which disallows fallback to cache when revalidation fails, and
+instead follows the behavior dictated by the
+.B hard
+or
+.B soft
+mount option.
+.TP 1.5i
 .BR intr " / " nointr
 This option is provided for backward compatibility.
 It is ignored after kernel 2.6.25.
-- 
2.21.1


  reply	other threads:[~2020-01-29 15:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 15:47 [PATCH 1/2] manpage: Add a description of the 'nconnect' mount option Steve Dickson
2020-01-29 15:47 ` Steve Dickson [this message]
2020-02-07 16:08   ` [PATCH 2/2] manpage: Add a description of the 'softreval' / 'nosoftreval' " Steve Dickson
2020-02-03 15:15 ` [PATCH 1/2] manpage: Add a description of the 'nconnect' " Olga Kornievskaia
2020-02-04 16:46   ` Steve Dickson
2020-02-04 17:13     ` Trond Myklebust
2020-02-04 17:22       ` Olga Kornievskaia
2020-02-04 17:36         ` Trond Myklebust
2020-02-07 16:08 ` Steve Dickson

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=20200129154703.6204-2-steved@redhat.com \
    --to=steved@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.