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. > > (Out of curiosity: have you seen this cause actual bugs?) > Not so much bugs, but it definitely causes inefficiencies. The client has to go to the server for every one of the WCC GETATTR calls, and needs to serialise that with the operations. It's just a latency hog for very little gain when you are doing bulk writing. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
