Eric, On 25 Apr 2016, at 14:55, Eric Blake <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
