diff options
author | Eric Blake <eblake@redhat.com> | 2017-11-06 21:09:11 -0600 |
---|---|---|
committer | Eric Blake <eblake@redhat.com> | 2018-01-08 09:12:23 -0600 |
commit | 418638d3e448e0ed79d55cc43a26f7a65c22007f (patch) | |
tree | db8bfcc61d6ed96ef88fee003124339cc2366a9c /util/cacheinfo.c | |
parent | 799044b6a3a0fc63e1e020e4d9266786a2dc7a0b (diff) |
nbd/server: Implement sparse reads atop structured reply
The reason that NBD added structured reply in the first place was
to allow for efficient reads of sparse files, by allowing the
reply to include chunks to quickly communicate holes to the client
without sending lots of zeroes over the wire. Time to implement
this in the server; our client can already read such data.
We can only skip holes insofar as the block layer can query them;
and only if the client is okay with a fragmented request (if a
client requests NBD_CMD_FLAG_DF and the entire read is a hole, we
could technically return a single NBD_REPLY_TYPE_OFFSET_HOLE, but
that's a fringe case not worth catering to here). Sadly, the
control flow is a bit wonkier than I would have preferred, but
it was minimally invasive to have a split in the action between
a fragmented read (handled directly where we recognize
NBD_CMD_READ with the right conditions, and sending multiple
chunks) vs. a single read (handled at the end of nbd_trip, for
both simple and structured replies, when we know there is only
one thing being read). Likewise, I didn't make any effort to
optimize the final chunk of a fragmented read to set the
NBD_REPLY_FLAG_DONE, but unconditionally send that as a separate
NBD_REPLY_TYPE_NONE.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20171107030912.23930-2-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Diffstat (limited to 'util/cacheinfo.c')
0 files changed, 0 insertions, 0 deletions