Re: [Nbd] Question about the expected behaviour of nbd-server for async ops
- To: Alex Bligh <alex@...872...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] Question about the expected behaviour of nbd-server for async ops
- From: Wouter Verhelst <w@...112...>
- Date: Sun, 29 May 2011 09:05:17 +0200
- Message-id: <20110529070517.GB25100@...510...>
- In-reply-to: <20110529065038.GA25100@...510...>
- References: <87oc2m28o7.fsf@...860...> <6DBA2A6208847F844397DB62@...873...> <20110529065038.GA25100@...510...>
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.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: