On Wed, Feb 11, 2015 at 11:13:38AM -0500, Trond Myklebust wrote: > On Wed, Feb 11, 2015 at 11:04 AM, Anna Schumaker > <Anna.Schumaker@xxxxxxxxxx> wrote: > > I'm not seeing a huge performance increase with READ_PLUS compared to READ (in fact, it's often a bit slower compared to READ, even when using splice). My guess is that the problem is mostly on the client's end since we have to do a memory shift on each segment to get everything lined up properly. I'm playing around with code that cuts down the number of memory shifts, but I still have a few bugs to work out before I'll know if it actually helps. > > > > I'm wondering if the right way to do READ_PLUS would have been to > instead have a separate function READ_SPARSE, that will return a list > of all sparse areas in the supplied range. We could even make that a > READ_SAME, that can do the same for patterned data. I worry about ending up with incoherent results, but perhaps it's no different from the current behavior since we're already piecing together our idea of the file content from multiple reads sent in parallel. > The thing is that READ works just fine for what we want it to do. The > real win here would be if given a very large file, we could request a > list of all the sparse areas in, say, a 100GB range, and then use that > data to build up a bitmap of unallocated blocks for which we can skip > the READ requests. Can we start by having the server return a single data extent covering the whole read request, with the single exception of the case where the read falls entirely within a hole? I think that should help in the case of large holes without interfering with the client's zero-copy logic in the case there are no large holes. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
