Re: [Nbd] Question about the expected behaviour of nbd-server for async ops

[Goswin v. B. <gos...@we...>]

Wouter Verhelst <w...@ut...> writes:

> On Sun, May 29, 2011 at 08:50:38AM +0200, Wouter Verhelst wrote:
>> > Handles can be reused only once the command in question is completed.
>> > 
>> > You may process commands out of order, and reply out of order,
>> > save that
>> > a) all write commands *completed* before you process a REQ_FLUSH
>> >    must be written to non-volatile storage prior to completing
>> >    that REQ_FLUSH (though apparently you should, if possible, make
>> >    this true for all write commands *received*, which is a stronger
>> >    condition) [Ignore this if you don't set SEND_REQ_FLUSH]
>> 
>> We already implement that stronger condition, because writes are handled
>> in the way they are received. It shouldn't be too hard to implement when
>> disordered handling of requests is done, either: stop handling incoming
>> requests when you receive a flush request; flag all outstanding requests
>> so you know when the flush can be done (after which you can start
>> handling incoming requests again); and handle the flush when all flagged
>> requests have been handled.
>
> Better yet: don't stop handling and loop over them to flag, which will
> take time; instead, just create a new queue of requests to handle, and
> only handle the FLUSH request once the old queue is empty.

I don't have a queue of pending requests in my design. Instead I've been
considering giving each request an id (uint64_t monoton rising). A flush
gets a counter, initialized with the number of currently pending
requests, and every reply which id is smaller than the flushes
decrements the counter. On reaching 0 the flush request can be
ACKed. But the idea is basically the same.

This would not scale well with many flush requests in parallel but I
hope it is save to assume there usualy won't be many (or even more than
one).

MfG
        Goswin