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@xxxxxxxxxxx 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.
