From: Vasily Averin <vvs@virtuozzo.com>
To: "J. Bruce Fields" <bfields@fieldses.org>,
Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
"Denis V. Lunev" <den@virtuozzo.com>,
Cyrill Gorcunov <gorcunov@virtuozzo.com>,
Konstantin Khorenko <khorenko@virtuozzo.com>
Subject: Re: [PATCH] nfs: block notification on fs with its own ->lock
Date: Fri, 17 Dec 2021 09:41:03 +0300 [thread overview]
Message-ID: <bb7b5a71-6ddf-5e22-e555-8ae22e5930fe@virtuozzo.com> (raw)
In-Reply-To: <20211216172013.GA13418@fieldses.org>
On 16.12.2021 20:20, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> NFSv4.1 supports an optional lock notification feature which notifies
> the client when a lock comes available. (Normally NFSv4 clients just
> poll for locks if necessary.) To make that work, we need to request a
> blocking lock from the filesystem.
>
> We turned that off for NFS in f657f8eef3ff "nfs: don't atempt blocking
> locks on nfs reexports" because it actually blocks the nfsd thread while
> waiting for the lock.
>
> Thanks to Vasily Averin for pointing out that NFS isn't the only
> filesystem with that problem.
>
> Any filesystem that leaves ->lock NULL will use posix_lock_file(), which
> does the right thing. Simplest is just to assume that any filesystem
> that defines its own ->lock is not safe to request a blocking lock from.
>
> So, this patch mostly reverts f657f8eef3ff and b840be2f00c0, and instead
> uses a check of ->lock (Vasily's suggestion) to decide whether to
> support blocking lock notifications on a given filesystem. Also add a
> little documentation.
>
> Perhaps someday we could add back an export flag later to allow
> filesystems with "good" ->lock methods to support blocking lock
> notifications.
>
> Reported-by: Vasily Averin <vvs@virtuozzo.com>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Reviewed-by: Vasily Averin <vvs@virtuozzo.com>
next prev parent reply other threads:[~2021-12-17 6:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 17:20 [PATCH] nfs: block notification on fs with its own ->lock J. Bruce Fields
2021-12-17 6:41 ` Vasily Averin [this message]
2021-12-17 16:11 ` Chuck Lever III
2021-12-21 11:31 ` Pratyush Yadav
2021-12-21 15:13 ` Chuck Lever III
2021-12-21 19:30 ` Pratyush Yadav
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=bb7b5a71-6ddf-5e22-e555-8ae22e5930fe@virtuozzo.com \
--to=vvs@virtuozzo.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=den@virtuozzo.com \
--cc=gorcunov@virtuozzo.com \
--cc=jlayton@kernel.org \
--cc=khorenko@virtuozzo.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