[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/12] nbd improvements

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/12] nbd improvements
Date: Fri, 09 Sep 2011 13:00:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 09/09/2011 12:50 PM, Nicholas Thomas wrote:
>  On the other hand, Nicholas's work includes timeout and reconnect.  I'm
>  not sure how complicated it is to include it in my series, but probably
>  not much.  With coroutines, preserving the list of outstanding I/O
>  requests is done implicitly by the CoMutex, so you basically have to
>  check errno for ECONNRESET and similar errors, reconnect, and retry
>  issuing the current request only.
Definitely a simpler approach than my version. Although, does your
version preserve write ordering? I was quite careful to ensure that
write requests would always be sent in the order they were presented;
although I don't know if qemu proper depends on that behaviour or not.

Yes, the current operation does not drop the CoMutex until the error goes away. Ordering is preserved because in turn no request can start until the first leaves the coroutine (with the CoMutex locked).

Anyway I think the guests do not depend on it, there is no ordering guarantee in the AIO thread pool. If any of the more advanced file formats do, that would be a bug.

>  Timeout can be done with a QEMUTimer that shuts down the socket
>  (shutdown(2) I mean).  This triggers an EPIPE when writing, or a
>  zero-sized read when reading.  The timeout can be set every time the
>  coroutine is (re)entered, and reset before exiting nbd_co_readv/writev.
for reconnect, I did consider using QEMUTimer, but when I tried it I ran
into linking problems with qemu-io.   As far as I can tell, resolving that
is a significant code reorganisation - QEMUTimer pulls in lots of code
that isn't linked in at the moment (VM clocks, etc). I'm not sure it's
worth tackling that to avoid using timer_create(2).

I agree. I think it's worth it because it would help Anthony's work with unit testing too; but it's also a significant amount of work. But in this sense, keeping each feature in a separate patch helps a lot. If something is done in a hacky way, it's much easier to redo it later if "git show" gives a good overview of how it was done.

I saw earlier versions of your patch had problems with the upstream nbd server. It works for me, but you'd be welcome trying out my series.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]