qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits ha


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash
Date: Mon, 22 Feb 2016 09:37:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 02/22/2016 06:31 AM, Alberto Garcia wrote:

> The way I see it is that if we have, say, 5 drives with a threshold of 3
> and flushing fails in one of them Quorum should report the error (with
> QUORUM_REPORT_BAD probably, or maybe a new event) but succeed, because
> we have at least 3 images that are (in principle) fine. I don't see why
> the guest should see an error in that case.

Yes, I can live with that.  Basically, treat flushing like everything
else quorum - follow the same voting rules (either you are in threshold
mode, and must meet the threshold to succeed while issuing an event for
the failing outliers; or you are in FIFO mode and the first success is
sufficient).


> I think the correct solution would be something like the code in V10 but
> counting the number of correct flushes and using them to decide whether
> to report an error or not. Something like this:
> 
>     for (i = 0; i < s->total; i++) {
>         result = bdrv_co_flush(s->bs[i]);
>         if (result) {
>             result_value.l = result;
>             quorum_count_vote(&error_votes, &result_value, i);
>         } else {
>             correct++;
>         }
>     }
> 
>     if (correct < s->threshold) {
>         winner = quorum_get_vote_winner(&error_votes);
>         result = winner->value.l;
>     }
> 
>> Anyway, regardless of that, if we do take the threshold into account,
>> we should not use the exact error value for voting but just whether an
>> error occurred or not. If all but one children fail to flush (all for
>> different reasons), I find it totally wrong to return success. We
>> should then just return -EIO or something.
> 
> Exactly. I think -EIO should be fine, I'm not sure why it was proposed
> to vote the return code in this case?
> 
> It doesn't seem that there was any discussion other than this question
> from Eric:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04034.html

My concern there was the complete disregard for errors.  With your
proposal here, errors are voted on the same as they are for reads and
writes, which feels like the correct approach.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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