On Thu, Aug 29, 2024 at 01:52:40PM +0000, Chuck Lever III wrote: > > > > On Aug 29, 2024, at 12:00 AM, Christoph Hellwig <hch@xxxxxx> wrote: > > > >> Wouldn't readplus (and maybe a sparse copy program) rather have > >> something that is "SEEK_DATA, fill the buffer with data from that file > >> position, and tell me what pos the data came from"? > > > > Or rather a read operation that returns a length but no data if there > > is a hole. Right, it needs to be an iomap level operation - if the map returned is a hole it records a hole, otherwise it reads the through the page cache. But to do this, we need the buffered reads to hit the filesystem first and get the mapping to determine how to process the incoming read operation, not go through the page cache first and bypass the fs entirely because there are cached pages full of zeroes in the page cache over the hole... > That is essentially what READ_PLUS does. The "HOLE" array > members are a length. The receiving client is then free > to represent that hole in whatever way is most convenient. > > NFSD can certainly implement READ_PLUS so that it returns > only a single array element -- and that element would be > either CONTENT or HOLE -- in a possibly short read result. > (That might be what it is doing already, come to think of > it). > > The problem with SEEK_DATA AIUI is that READ_PLUS wants > a snapshot of the file's state. SEEK_DATA is a separate > operation, so some kind of serialization would be > necessary to prevent file changes between reads and seeks. Note that SEEK_DATA also handles unwritten extents correct. It will report them as a hole if there is no cached data over the range, otherwise it will be considered data. The only downside of this is that if the unwritten extent has been read and the page cache contains clean zeroed folios, SEEK_DATA will always return that unwritten range as data. IOWs, unwritten extent mappings for READPLUS would need special handling to only return data if the page cache folios over the unwritten range are dirty... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
