From: "J. Bruce Fields" <bfields@fieldses.org>
To: Kinglong Mee <kinglongmee@gmail.com>
Cc: NeilBrown <neilb@suse.de>,
linux-fsdevel@vger.kernel.org,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Trond Myklebust <trond.myklebust@primarydata.com>
Subject: Re: [PATCH 4/4] nfsd: Pin to vfsmnt instead of mntget
Date: Fri, 22 May 2015 12:03:52 -0400 [thread overview]
Message-ID: <20150522160352.GC5580@fieldses.org> (raw)
In-Reply-To: <555F4501.2090806@gmail.com>
On Fri, May 22, 2015 at 11:02:25PM +0800, Kinglong Mee wrote:
> On 5/16/2015 7:23 AM, NeilBrown wrote:
> > On Fri, 15 May 2015 17:11:34 -0400 "J. Bruce Fields" <bfields@fieldses.org>
> > wrote:
> >
> >> On Wed, May 13, 2015 at 02:25:15PM +1000, NeilBrown wrote:
> >>> On Mon, 11 May 2015 21:08:47 +0800 Kinglong Mee <kinglongmee@gmail.com> wrote:
> >>>
> >>>> On 5/8/2015 9:47 PM, J. Bruce Fields wrote:
> >>>>> It could also be useful to have the ability to force an unmount even in
> >>>>> the presence of locks. That's not a safe default, but an
> >>>>> "allow_force_unmount" export option might be useful.
> >>>
> >>> We already have a mechanism to forcibly drop any locks by writing some magic
> >>> to /proc/fs/nfsd/unlock_{ip,filesystem}. I don't think we need any more.
> >>
> >> Yeah, I remember thinking this sort of approach would have advantages,
> >> maybe I was wrong, I need to revisit it.
> >>
> >> The unlock_{ip,filesystem} approach requires temporarily shutting down
> >> mountd, doesn't it?
> >
> > Not necessarily.
> > It does require ensuring that new locks aren't suddenly taken though.
> >
> > I imagine an early step in the migration process is to "ifconfig down" the
> > virtual interface with the floating ID. Then you can safely "unlock" and
> > unmount any filesystems are that only accessed via the IP.
> >
> > But you are right that using the "unlock_*" interface and then unmounting is
> > racy in a way that we are trying to make "unmount" not racy. So maybe an
> > "allow_force_unmount" would have a place.
>
> No, unlock_{ip,filesystem} are used for nlmlock, doesn't support nfsv4 resources.
I still prefer the "allow_force_unmount" option, but maybe we should
also fix unlock_{ip,filesystem} to deal with nfsv4. (Though I think
it's a little less well-defined there due to the possibility of
trunking.)
> Some other interfaces under /sys/kernel/debug/nfsd/forget_* support nfsv4 resources,
> without for an filesystem. It seems will be removed sometime.
We definitely don't want people to depend on those for anything other
than testing clients.
I don't think they'd be practical for this use. forget_client comes the
closest, but you'd have to figure out the ip address of every client you
want to forget. If there's a risk people might try to really use that,
then maybe we should go for scarier warnings and/or remove that
particular interface.
--b.
next prev parent reply other threads:[~2015-05-22 16:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 13:18 [PATCH 0/4] NFSD: Pin to vfsmount instead of mntget for export cache Kinglong Mee
[not found] ` <554A149B.5060102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-06 13:19 ` [PATCH 1/4] fs_pin: Fix uninitialized value in fs_pin Kinglong Mee
2015-05-07 19:43 ` J. Bruce Fields
[not found] ` <20150507194335.GA16527-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2015-05-08 0:36 ` Kinglong Mee
2015-05-06 13:19 ` [PATCH 2/4] fs_pin: Export functions for specific filesystem Kinglong Mee
2015-05-06 13:20 ` [PATCH 3/4] sunrpc: New helper cache_force_expire for cache cleanup Kinglong Mee
2015-05-06 13:21 ` [PATCH 4/4] nfsd: Pin to vfsmnt instead of mntget Kinglong Mee
2015-05-08 4:40 ` NeilBrown
2015-05-08 13:47 ` J. Bruce Fields
2015-05-11 13:08 ` Kinglong Mee
[not found] ` <5550A9DF.1070908-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-13 4:25 ` NeilBrown
2015-05-13 12:30 ` Kinglong Mee
[not found] ` <555343CA.6010307-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-13 12:55 ` Kinglong Mee
[not found] ` <20150513142515.6bd881c8-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2015-05-15 21:11 ` J. Bruce Fields
2015-05-15 23:23 ` NeilBrown
2015-05-22 15:02 ` Kinglong Mee
2015-05-22 16:03 ` J. Bruce Fields [this message]
2015-05-15 21:09 ` 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=20150522160352.GC5580@fieldses.org \
--to=bfields@fieldses.org \
--cc=kinglongmee@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--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).