On Wed, Jul 20, 2022 at 08:55:23AM -0400, Jeff Layton wrote: > On Wed, 2022-07-20 at 12:36 +1000, Dave Chinner wrote: > > > Now how does the server make that choice? Is there an attribute > > > bit that indicates when a file should be treated as sparse? Can > > > we assume that immutable files (or compressed files) should > > > always be treated as sparse? Alternately, the server might use > > > the file's data : hole ratio. > > > > None of the above. The NFS server has no business knowing intimate > > details about how the filesystem has laid out the file. All it cares > > about ranges containing data and ranges that have no data (holes). > > > > If the filesystem can support a sparse read, it returns sparse > > ranges containing data to the NFS server. If the filesystem can't > > support it, or it's internal file layout doesn't allow for efficient > > hole/data discrimination, then it can just return the entire read > > range. > > > > Alternatively, in this latter case, the filesystem could call a > > generic "sparse read" implementation that runs memchr_inv() to find > > the first data range to return. Then the NFS server doesn't have to > > code things differently, filesystems don't need to advertise > > support for sparse reads, etc because every filesystem could > > support sparse reads. > > > > The only difference is that some filesystems will be much more > > efficient and faster at it than others. We already see that sort > > of thing with btrfs and seek hole/data on large cached files so I > > don't see "filesystems perform differently" as a problem here... > > > > ^^^ > This seems like more trouble than it's worth, and would probably result > in worse performance. The generic implementation should just return a > single non-sparse extent in the sparse read reply if it doesn't know how > to fill out a sparse read properly. IOW, we shouldn't try to find holes, > unless the underlying filesystem can do that itself via iomap sparse > read or some similar mechanism. Yup, that's what I'd suggest initially, then a separate investigation can be done to determine if manual hole detection is worth the effort for those filesystems that cannot support sparse reads effectively. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
