On Mon, 2020-11-30 at 17:58 -0500, J. Bruce Fields wrote: > This is great, thanks: > > On Mon, Nov 30, 2020 at 04:24:50PM -0500, trondmy@xxxxxxxxxx wrote: > > From: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> > > > > With NFSv3 nfsd will always attempt to send along WCC data to the > > client. This generally involves saving off the in-core inode > > information > > prior to doing the operation on the given filehandle, and then > > issuing a > > vfs_getattr to it after the op. > > > > Some filesystems (particularly clustered or networked ones) have an > > expensive ->getattr inode operation. Atomicitiy is also often > > difficult > > or impossible to guarantee on such filesystems. For those, we're > > best > > off not trying to provide WCC information to the client at all, and > > to > > simply allow it to poll for that information as needed with a > > GETATTR > > RPC. > > > > This patch adds a new flags field to struct export_operations, and > > defines a new EXPORT_OP_NOWCC flag that filesystems can use to > > indicate > > that nfsd should not attempt to provide WCC info in NFSv3 replies. > > It > > also adds a blurb about the new flags field and flag to the > > exporting > > documentation. > > In the v4 case I think it should also turn off the "atomic" flag in > the > change_info4 structure that's returned by some operations. > To answer this comment (which I missed earlier): I don't know that we can turn off WCC for NFSv4. The GETATTR is a completely separate operation, so the server would have to second-guess what the client needs it for in order to optimise it away. That is why this patch is labelled as being an optimisation for NFSv3 only in the comments above. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
