On Fri, Feb 22, 2019 at 04:58:48PM -0500, Anna Schumaker wrote: > These patches add server support for the READ_PLUS operation. This > operation is meant to improve file reading performance when working with > sparse files, but there are some issues around the use of vfs_llseek() to > identify hole and data segments when encoding the reply. I've done a > bunch of testing on virtual machines, Maybe the VM<->VM case is important too, but it'd be a little easier to understand a case with real hardware, I think. What kind of disk are you using, our of curiosity? Also, what are the file sizes, and the rsize? (Apologies if I overlooked that.) > and I found that READ_PLUS performs best if: It's interesting to think about why these are: > 1) The file being read is not yet in the server's page cache. I don't understand this one. > 2) The read request begins with a hole segment. And If I understand your current implementation, it's basically: - seek with SEEK_DATA. - if that finds a hole, read the rest of the requested range and return two segments (a hole plus ordinary read results) - otherwise just return ordinary read data for the whole range. So, right, in the case the read range starts with data, the seek was just a waste of time, makes sense. > 3) The server only performs one llseek() call during encoding OK, so for that we'd need to compare to a different implementation, which is what you did elsewhere: > I also have performance numbers for if we encode every hole and data > segment but I figured this email was long enough already. I'm happy to > share it if requested! Got it. (And, sure, that might be interesting.) --b.
