Eric, On 25 Apr 2016, at 14:55, Eric Blake <eblake@...696...> wrote: >> Is the current structured-reply extension incredibly baroque for no gain? > > No, I still think we want the full flexibility of multiple chunks. > Remember, the BIG gain is the ability to read holes without sending > zeros over the wire. Ah yes, I forgot this. > You cannot get that without multiple chunks, or > else by constraining your maximum block size to be relatively small > (aren't there file systems with holes at the granularity of 32k?). There certainly are if the offset isn't 32k aligned :-) > Requiring the client to only read 32k at a time in order to efficiently > report holes seems like it will cause more traffic overhead. > > Other benefits from structured replies: error messages to accompany an > error chunk, and the ability to implement the BLOCK_STATUS extension > (proposals have been floated on list, but right now we still don't have > an extension-* branch for it). True. >> Could we do something much simpler if we assume that the 'chunking' is done by the BLOCKSIZE stuff? >> > > I don't think so, because the ability to read holes is the main reason I > added chunking of the read reply. Yes. Fair enough. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail