Re: [bug report] nfs clients fail to get read delegations after file open with O_RDWR

[Jeff Layton <jlayton@kernel.org>]

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:
> > Thanks for your quick reply!
> > 
> > > > Without looking at this case in detail:
> > 
> > > > Delegations are granted at the server's discretion, so this certainly
> > > > isn't a bug.
> > 
> > Got it.
> > 
> > > > It might be suboptimal behavior.  If there's evidence that this causes
> > > > significant regressions on some important workload, then we'd want to
> > > > look into fixing it.
> > 
> > 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.
> 
> Right.
> 
> For the moment, this is something I'd accept patches for, but I'm not
> actively working on.
> 
> I think it's been suggested that we could even turn off the file cache
> completely in the v4 case, since in that case we don't have to re-open
> on every IO.
> 

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?
-- 
Jeff Layton <jlayton@kernel.org>