Re: [Nbd] [RFC] Proposal: NBD_CMD_READ2
- To: Wouter Verhelst <w@...112...>
- Cc: "email@example.com" <firstname.lastname@example.org>
- Subject: Re: [Nbd] [RFC] Proposal: NBD_CMD_READ2
- From: Alex Bligh <alex@...872...>
- Date: Thu, 20 Aug 2015 17:30:35 +0100
- Message-id: <1EF9BCFA-A931-4373-A7D0-FA9AD3BFED8E@...872...>
- In-reply-to: <20150820134441.GB27381@...3...>
- References: <20150820110519.GA17039@...3...> <AE44BFF5-25F7-495E-80AA-A91947526A2A@...872...> <20150820131754.GE18784@...1897...> <20150820134441.GB27381@...3...>
On 20 Aug 2015, at 14:44, Wouter Verhelst <w@...112...> 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
>> 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