On 20 Aug 2015, at 14:44, Wouter Verhelst <[email protected]> wrote: >> I like the idea of blocks. However I think it would be better to have >> some kind of negotiation for the maximum block size for reads and >> writes. >> >> As the server can choose the size of a block itself I think it wouldn't >> be a problem to have a header for each data block which has the >> error state and so on. Then we wouldn't have this strange semantic of >> reporting the error state of the data we already transmitted. > > That would make doing things like using sendfile() to send out the > actual data impossible, as when you use sendfile(), you don't know that > an error occurred until you've put some of the data on the wire already. > > (unless I'm missing things, which of course is possible)
Yep, this was why I was planning to leave the fragmentation of replies up to the server. However, thinking about it, one could still do what Markus suggests at the expense of some complexity server side - requests larger than the maximum specified by the client would merely have to be split server side into multiple sendfiles. But I'm not entirely convinced of the need for the client to be able to specify a maximum fragment size. If the client doesn't want more than n MB in a fragment, it simply fragments its own requests into multiple NBD_CMD_READ2 commands. -- Alex Bligh ------------------------------------------------------------------------------ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
