Re: [Nbd] request queue

[Goswin von Brederlow <goswin-v-b@...186...>]

On Tue, Mar 12, 2013 at 09:47:02AM +0100, folkert wrote:
> > > What about adding something to the NBD protocol which tells the server
> > > that x requests are coming in and that the client will not wait for an
> > > acknowledgement before it has send all requests and/or data for those x
> > > requests?
> > > Because then a server can pull in all requests in one go and then start
> > > to fiddle with the disk. Or do things intelligent in parallel (if you
> > > have multiple spindels). etc.
> > 
> > I don't see why we need to change the protocol for that? It's already
> > possible to handle requests in parallel. The client can (and does)
> > alrady have multiple outstanding requests; it's just that the current
> > server implementation doesn't handle them in parallel.
> 
> Problem is that a server does not know that it can wait for more
> requests to come in for which it can wait. With the enhancement it knows
> that it can input multiple requests and then process them.
> Like iSCSI does.
> 
> 
> Folkert van Heusden

What you do is use select, poll, epoll or even simply a blocking read
to wait for requests to come in. Then you parse the request and fire
of the IO asynchronously with either libaio, posix_aio (threads) or
worker threads. And then you go right back waiting for the next
request to come in.

The NBD protocol is such that multiple requests may be send in
parallel and can complete in any order unless FUA/FLUSH is used. It is
the clients job to ensure data consistency irespective of the order in
which requests are handled.

The current nbd server handles requests strictly in order, waiting for
the completion of one before starting another. That is perfeclty in
line with the protocol, it just doesn't take advantage of all the
freedom. But that is due to lack of someone rewriting the server to do so.

MfG
	Goswin

PS: a few people have written their own servers that do async IO.