From: Joshua Watt <jpewhacker@gmail.com>
To: NeilBrown <neilb@suse.com>, Jeff Layton <jlayton@redhat.com>,
Trond Myklebust <trond.myklebust@primarydata.com>
Cc: linux-nfs@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
"J . Bruce Fields" <bfields@fieldses.org>,
David Howells <dhowells@redhat.com>,
Joshua Watt <JPEWhacker@gmail.com>
Subject: [RFC 0/4] Re: NFS Force Unmounting
Date: Wed, 8 Nov 2017 08:59:38 -0600 [thread overview]
Message-ID: <20171108145942.5127-1-JPEWhacker@gmail.com> (raw)
In-Reply-To: <CAJdd5GZ-EMj8f3RaV_WUdeZs6aWbEAeC6xX8BadMD-aOFL3_jA@mail.gmail.com>
This was my attempt at solving the force unmounting problem, which I
though I would post for discussion (as sort of a alternate to Neil's
patch).
I think there are a few advantages to this approach:
1) "umount -f" pretty much always does what you want if you have
"forcekill" in your mount options
2) It is easy to separate out at an administrative level what mounts
will be affected by "umount -f", because the "forcekill" mount
option affects the decision as to whether the NFS superblock can be
shared (e.g. only mounts to the same client with the same state of
the forcekill flag are shared, and thus affected by umount -f)
3) I think this will catch all the different types of RPCs
(asynchronous, etc.) for a given client?
And a few disadvantages:
1) It requires a new mount option (maybe there is another way? A mount
option was all I could figure to prevent superblock sharing).
2) It doesn't currently affect the behavior of the DESTROY_SESSION RPC
call made by the nfs_client when the last superblock reference is
removed. This means that this call must go through the normal
recovery and timeout process. I am OK with this behavior (for my use
case at least) because that is *only* going to block the umount
caller for a (bounded) amount of time.
3) Probably more I haven't though of...
I don't claim to be a Linux Kernel NFS or filesystem expert, so I will
leave the decisions to those who have a better understanding.
Also, this is my first (non-trivial) Linux kernel patch, so any sort of
review and comments are greatly appreciated.
Thanks!
Joshua Watt (4):
SUNRPC: Add flag to kill new tasks
SUNRPC: Kill client tasks from debugfs
SUNRPC: Simplify client shutdown
NFS: Add forcekill mount option
fs/nfs/super.c | 17 ++++++++++++---
include/linux/sunrpc/clnt.h | 1 +
include/linux/sunrpc/sched.h | 2 +-
include/uapi/linux/nfs_mount.h | 1 +
net/sunrpc/clnt.c | 13 +++++++++---
net/sunrpc/debugfs.c | 48 ++++++++++++++++++++++++++++++++++++++++++
net/sunrpc/sched.c | 7 ++++++
7 files changed, 82 insertions(+), 7 deletions(-)
--
2.13.6
next prev parent reply other threads:[~2017-11-08 15:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-25 17:11 NFS Force Unmounting Joshua Watt
2017-10-30 20:20 ` J. Bruce Fields
2017-10-30 21:04 ` Joshua Watt
2017-10-30 21:09 ` NeilBrown
2017-10-31 14:41 ` Jeff Layton
2017-10-31 14:55 ` Chuck Lever
2017-10-31 17:04 ` Joshua Watt
2017-10-31 19:46 ` Chuck Lever
2017-11-01 0:53 ` NeilBrown
2017-11-01 2:22 ` Chuck Lever
2017-11-01 14:38 ` Joshua Watt
2017-11-02 0:15 ` NeilBrown
2017-11-02 19:46 ` Chuck Lever
2017-11-02 21:51 ` NeilBrown
2017-11-01 17:24 ` Jeff Layton
2017-11-01 23:13 ` NeilBrown
2017-11-02 12:09 ` Jeff Layton
2017-11-02 14:54 ` Joshua Watt
2017-11-08 3:30 ` NeilBrown
2017-11-08 12:08 ` Jeff Layton
2017-11-08 15:52 ` J. Bruce Fields
2017-11-08 22:34 ` NeilBrown
2017-11-08 23:52 ` Trond Myklebust
2017-11-09 19:48 ` Joshua Watt
2017-11-10 0:16 ` NeilBrown
2017-11-08 14:59 ` Joshua Watt [this message]
2017-11-08 14:59 ` [RFC 1/4] SUNRPC: Add flag to kill new tasks Joshua Watt
2017-11-10 1:39 ` NeilBrown
2017-11-08 14:59 ` [RFC 2/4] SUNRPC: Kill client tasks from debugfs Joshua Watt
2017-11-10 1:47 ` NeilBrown
2017-11-10 14:13 ` Joshua Watt
2017-11-08 14:59 ` [RFC 3/4] SUNRPC: Simplify client shutdown Joshua Watt
2017-11-10 1:50 ` NeilBrown
2017-11-08 14:59 ` [RFC 4/4] NFS: Add forcekill mount option Joshua Watt
2017-11-10 2:01 ` NeilBrown
2017-11-10 14:16 ` Joshua Watt
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=20171108145942.5127-1-JPEWhacker@gmail.com \
--to=jpewhacker@gmail.com \
--cc=bfields@fieldses.org \
--cc=dhowells@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.com \
--cc=trond.myklebust@primarydata.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).