[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_whic
From: |
Peter Lieven |
Subject: |
Re: [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_which_events |
Date: |
Wed, 08 Apr 2015 21:36:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Am 08.04.2015 um 21:22 schrieb Stefan Hajnoczi:
> On Wed, Apr 8, 2015 at 6:08 PM, ronnie sahlberg
> <address@hidden> wrote:
>> The nice part with the current patch of Peter is that qemu and
>> libiscsi can be upgraded/downgraded independently.
> That's fine for avoiding hassles for existing apps, like QEMU, and I'm
> happy to merge the patch.
>
> For the library's API design it would be return the timeout so that
> new applications can avoid polling, but that's just a suggestion.
You are right. Paolo also brought up this idea, but as Ronnie said the
idea was not to bump the API version. The whole async reconnect stuff
works without a change in the client.
But polling every 250ms is magnitutes better than having a hung Qemu :-)
If you feel 250ms is too often we could also go to 1000ms. The timeout
we are talking about is in the order of 1-30 seconds. It only happens when
a reconnect is initiated either bei Qemu (due to NOP timeout) or libiscsi
(protocol,
socket error etc.) and the first reconnect try is not successful.
Another idea I had was to encode the timeout in the return value of
iscsi_which_events.
This would work with all Qemu versions, but I do not know how poll reacts if it
gets
unknown events passed. So all users other than Qemu that pass the result of
iscsi_which_events
directly to poll would need to mask the result. Thats not a problem for the
tools provided with libiscsi,
but I do not know how much other real users except Qemu are out there?
Peter