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: > > 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@xxxxxxxxxx>
