On Jan 6, 2014, at 17:32, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Mon, Jan 06, 2014 at 04:57:10PM -0500, Anna Schumaker wrote: >> These patches are my initial implementation of READ_PLUS. I still have a >> few issues to work out before they can be applied, but I wanted to submit >> them anyway to get feedback before going much further. These patches were >> developed on top of my earlier SEEK and WRITE_PLUS patches, and probably >> won't apply cleanly without them (I am willing to reorder things if necessary!). >> >> On the server side, I handle the cases where a file is 100% hole, 100% data >> or hole followed by data. Any holes after a data segment will be expanded >> to zeros on the wire. > > I assume that for "a file" I should read "the requested range of the > file"? > > hole+data+hole should also be doable, shouldn't it? I'd think the real > problem would be multiple data extents. > >> This is due to a limitation in the the NFSD >> encode-to-page function that will adjust pointers to point to the xdr tail >> after reading a file to the "pages" section. Bruce, do you have any >> suggestions here? > > The server xdr encoding needs a rewrite. I'll see if I can ignore you > all and put my head down and get a version of that posted this week. > > That should make it easier to return all the data, though it will turn > off zero-copy in the case of multiple data extents. > > If we want READ_PLUS to support zero copy in the case of multiple > extents then I think we need a new data structure to represent the > resulting rpc reply. An xdr buf only knows how to insert one array of > pages in the middle of the data. Maybe a list of xdr bufs? > > But that's an annoying job and possibly a premature optimization. > > It might be useful to first understand the typical distribution of holes > in a file and how likely various workloads are to produce reads with > multiple holes in the middle. Right. The main purpose of this patch set is to demonstrate that READ PLUS hole feature is pretty much useless in the cases you list above. Cheers Trond-- 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
