Re: [Nbd] another?

[Wouter Verhelst <w@...112...>]

On Fri, Sep 16, 2011 at 12:59:15PM +0100, Alex Bligh wrote:
> --On 16 September 2011 13:35:06 +0200 Wouter Verhelst <w@...112...> wrote:
> 
> >No, I think this should be fixed in the server, not the tester client.
> >This is a condition that the server needs to be able to deal with. The
> >fact that it doesn't is a bug in the server which the tester client only
> >exposed, it's not a bug in the tester client. If anything, it's a
> >feature of the tester client that it exposes a bug in the server.
> 
> Amusing as it is for this to be a 'it's my bug not your bug' discussion
> (the other way around from normal), I think it *is* my bug.
> 
> Essentially tester-client is not reading stuff if the write socket
> is blocked. The kernel never does this.
> 
> The server is quite within its rights to handle requests one at
> a time, i.e. read a request, deal with it in its entirety, and write
> the result. That's even in the protocol specification.
> 
> I break that, because of buffering, so I should fix it in the tester
> client. A simple example of me breaking it would be that I send
> a single large read request, which the client starts processing,

You mean to say that the server starts processing, right?

> which is larger than the socket buffers. Whilst this is happening, I start
> a single large write request which is again larger than the socket
> buffers.

Right.

> The client is entitled to fully process the read before it
> commences on the write, and to do so needs to write it to the socket.
> But it can't complete this write, because the socket buffer is full,
> as the tester client is busy writing and not reading.
> 
> This can't (as a general point) be fixed in the server without saying
> the server should have access to an infinite amount of memory. Suppose
> the write request overlapped the read? Where would it put it?

I thought we'd said that overlapping read or write requests are bad, and
the client should not do that (because the result will be
unpredictable), unless there's a FLUSH inbetween.

But yeah, the server should be able to eventually say "hold yer horses,
there's some stuff here that I want you to handle first". I think the
only reasonable way to do that is to have the client handle EAGAIN (or
NBD_ERR_AGAIN, as the case may be) in a reasonable manner.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a