All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: "suy.fnst@fujitsu.com" <suy.fnst@fujitsu.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"trond.myklebust@hammerspace.com"
	<trond.myklebust@hammerspace.com>,
	"bfields@redhat.com" <bfields@redhat.com>
Subject: Re: [bug report] nfs clients fail to get read delegations after file open with O_RDWR
Date: Tue, 14 Dec 2021 12:24:53 -0500	[thread overview]
Message-ID: <20211214172453.GA13957@fieldses.org> (raw)
In-Reply-To: <03f509d6889856869058e1bfb4d480524489354b.camel@kernel.org>

On Tue, Dec 14, 2021 at 12:19:54PM -0500, Jeff Layton wrote:
> On Tue, 2021-12-14 at 11:45 -0500, J. Bruce Fields wrote:
> > On Tue, Dec 14, 2021 at 12:50:53AM +0000, suy.fnst@fujitsu.com wrote:
> > > If I understand the case correctly, the most common workload it influences like:
> > > 
> > > One nfs client opens a file with flag O_WRONLY/O_RDWR, close it.
> > > Then some nfs clients open the file with O_RDONLY right now then it will prevent
> > > server to give any delegation to other clients.  It may cause many unnecessary
> > > requests from clients because lack of delegations.
...
> Is that really desirable behavior? There is the bloom filter in
> nfs4state.c too that prevents it from handing out a delegation too soon
> after a delegrecall.
> 
> The situation above doesn't involve a recall, but it _could_ have if the
> timing had been a little different. It's probably worth thinking about
> how the rules for this ought to work in all cases.
> 
> Should we be treating inodes that experience real delegation recalls
> differently from this case?

It's not hard to imagine common cases where clients would want to read a
file soon after it's written.  E.g. a distributed compile or processing
pipeline where clients are sitting there waiting for new files to appear
and then doing further processing on them when they do.  I guess the
creator would do something in that case to indicate when the writing was
done--maybe rename the file to a common directory, or send some kind of
signal outside of NFS.

--b.

      reply	other threads:[~2021-12-14 17:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13  3:39 [bug report] nfs clients fail to get read delegations after file open with O_RDWR suy.fnst
2021-12-13 21:55 ` J. Bruce Fields
2021-12-14  0:50   ` suy.fnst
2021-12-14 16:45     ` J. Bruce Fields
2021-12-14 17:19       ` Jeff Layton
2021-12-14 17:24         ` J. Bruce Fields [this message]

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=20211214172453.GA13957@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=suy.fnst@fujitsu.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
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.