[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] [RFC] Proposal: NBD_CMD_READ2



On Thu, Aug 20, 2015 at 05:30:35PM +0100, Alex Bligh wrote:
> 
> 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
> >> 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.

As I sad I can see some use cases for NBD over UDP. Following this idea
the packets should be split so that they fit into the routes MTU. If you
have a MTU of 1400 or something similar it would be quite some overhead
in processing and packet load to send one client request for each 1400
bytes that will be read.

Of course at the moment this is all completely hypothetical but in case
fragmentation is introduced we can think about other features that may
make use of this.

Best regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Attachment: signature.asc
Description: Digital signature


Reply to: