> On Feb 20, 2020, at 1:35 PM, Anna Schumaker <schumaker.anna@xxxxxxxxx> wrote: > > On Thu, 2020-02-20 at 13:30 -0500, Chuck Lever wrote: >>> On Feb 20, 2020, at 1:28 PM, Anna Schumaker <schumaker.anna@xxxxxxxxx> >>> wrote: >>> >>> On Thu, 2020-02-20 at 09:55 -0500, Chuck Lever wrote: >>> >>>> The down-side here is that would make NFSv4.2 on RDMA >>>> unable to recognize holes in files the same way as it >>>> does on TCP, and that's a pretty significant variation >>>> in behavior. Does "noreadplus" even deal with that? >>> >>> Setting "noreadplus" just causes the client to use the READ operation >>> instead, >>> so there should be no difference between v4.1 and v4.2 if the option is set. >> >> My concern is the difference between NFSv4.2 with noreadplus >> and NFSv4.2 with readplus. The former is not able to detect >> holes in files on the server, but the latter is. > > The client could still use lseek to detect holes. The client throws away the > hole information after xdr decoding, and zeroes out the corresponding pages for > the page cache. Then maybe that's an optimization for another day. The READ_PLUS reply can have hole information. The client could save itself some SEEK_HOLE operations if it cached that hole information somehow. But if "readplus" and "noreadplus" result in exactly the same hole retention behavior on our client, I guess there's no harm in using "noreadplus" instead, except for possible performance regression. An alternative to making "noreadplus" the default would be to temporarily add "noreadplus" semantics to the "proto=rdma" mount option, as a separate patch; maybe after some performance results show that it is necessary. That would keep the mount interface a little less complicated. -- Chuck Lever
