[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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, (continued)
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Max Reitz, 2016/02/20
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Changlong Xie, 2016/02/21
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Dr. David Alan Gilbert, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Changlong Xie, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Dr. David Alan Gilbert, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Kevin Wolf, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Dr. David Alan Gilbert, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Changlong Xie, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Alberto Garcia, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash, Alberto Garcia, 2016/02/22
- Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash,
Eric Blake <=