Re: [Nbd] Question about the expected behaviour of nbd-server for async ops
- To: Wouter Verhelst <w@...112...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] Question about the expected behaviour of nbd-server for async ops
- From: Goswin von Brederlow <goswin-v-b@...186...>
- Date: Sun, 29 May 2011 12:42:01 +0200
- Message-id: <87oc2lbxfq.fsf@...860...>
- In-reply-to: <20110529070517.GB25100@...510...> (Wouter Verhelst's message of "Sun, 29 May 2011 09:05:17 +0200")
- References: <87oc2m28o7.fsf@...860...> <6DBA2A6208847F844397DB62@...873...> <20110529065038.GA25100@...510...> <20110529070517.GB25100@...510...>
Wouter Verhelst <w@...112...> 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
Reply to: