Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
From: NeilBrown <neilb@suse.de>
To: Chuck Lever <chuck.lever@oracle.com>,
	Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Neil F Brown <nfbrown@suse.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: remounting hard -> soft
Date: Thu, 03 Oct 2019 10:27:21 +1000
Message-ID: <87y2y265cm.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <489FAE7A-F9CC-46A9-84FC-127487ADC0B3@oracle.com>

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

On Wed, Oct 02 2019, Chuck Lever wrote:

> Hi Trond-
>
> We (Oracle) had another (fairly rare) instance of a weekend maintenance
> window where an NFS server's IP address changed while there were mounted
> clients. It brought up the issue again of how we (the Linux NFS community)
> would like to deal with cases where a client administrator has to deal
> with a moribund mount (like that alliteration :-).

What exactly is the problem that this caused?

As I understand it, a moribund mount can still be unmounted with "-l"
and processes accessing it can still be killed ... except....
There are some waits the VFS/MM which are not TASK_KILLABLE and
probably should be.  I think that "we" definitely want "someone" to
track them down and fix them.

>
> Does remounting with "soft" work today? That seems like the most direct
> way to deal with this particular situation.

I don't think this does work, and it would be non-trivial (but maybe not
impossible) to mark all the outstanding RPCs as also "soft".
If we wanted to follow a path like this (and I suspect we don't), I
would hope that we could expose the server connection (shared among
multiple mounts) in sysfs somewhere, and could then set "soft" (or
"dead") on that connection, rather than having to do it on every mount
from the particular server.

NeilBrown

>
>
> --
> Chuck Lever

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02 14:57 Chuck Lever
2019-10-03  0:27 ` NeilBrown [this message]
2019-10-03 13:01   ` Chuck Lever
2019-10-04 15:25     ` Trond Myklebust

Reply instructions:

You may reply publically 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=87y2y265cm.fsf@notabene.neil.brown.name \
    --to=neilb@suse.de \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfbrown@suse.com \
    --cc=trond.myklebust@hammerspace.com \
    /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

Linux-NFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \
		linux-nfs@vger.kernel.org
	public-inbox-index linux-nfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git