From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXtUa-0005Oe-Au for qemu-devel@nongnu.org; Mon, 22 Feb 2016 11:37:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXtUX-0005ug-3Q for qemu-devel@nongnu.org; Mon, 22 Feb 2016 11:37:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXtUW-0005ua-S1 for qemu-devel@nongnu.org; Mon, 22 Feb 2016 11:37:45 -0500 References: <1455588944-29799-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1455588944-29799-2-git-send-email-xiecl.fnst@cn.fujitsu.com> <56C6D1CD.7010800@cn.fujitsu.com> <56C877F3.3070401@redhat.com> From: Eric Blake Message-ID: <56CB3957.6080009@redhat.com> Date: Mon, 22 Feb 2016 09:37:43 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gvRjlsUkXaQk0XvPAJJPsJhs5uMO8J7ex" Subject: Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , Max Reitz , Wen Congyang , Changlong Xie , qemu devel , Kevin Wolf Cc: "Dr. David Alan Gilbert" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gvRjlsUkXaQk0XvPAJJPsJhs5uMO8J7ex Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 bu= t > counting the number of correct flushes and using them to decide whether= > to report an error or not. Something like this: >=20 > for (i =3D 0; i < s->total; i++) { > result =3D bdrv_co_flush(s->bs[i]); > if (result) { > result_value.l =3D result; > quorum_count_vote(&error_votes, &result_value, i); > } else { > correct++; > } > } >=20 > if (correct < s->threshold) { > winner =3D quorum_get_vote_winner(&error_votes); > result =3D winner->value.l; > } >=20 >> 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. >=20 > Exactly. I think -EIO should be fine, I'm not sure why it was proposed > to vote the return code in this case? >=20 > It doesn't seem that there was any discussion other than this question > from Eric: >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --gvRjlsUkXaQk0XvPAJJPsJhs5uMO8J7ex Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWyzlXAAoJEKeha0olJ0NqkyEH/0DbegfggFoExFJfSw+M/xov isbp0hwbxGlr4SjQsW/F0R/TDvQS+fcgfeKQ3GK6mRJTVDIPd9W2QtC1jwseH8al /tT+yy/IaiIUQzqlrAHuzEbRe2na9E0mtuwDn04zb3DkhYERTpcaQx2T4BTl9DB1 eb5lsEmn3dTVDK90sH/6nitLFP5iqI81PR1oiJZXwf4uAUiS9BwelqqEJh6nNEYd 2jA/MUCxu20vlx16pySqtR5vx706AWfxSEXE5xXrnwpcyPfRKH+9n+2Fn2JWx1S9 Of8HK+E93ulhRuOtbAyWuwt6Kri/Xe4tJ9sH3jK75G65TUbCcTtMRmaCn8P3oeg= =PjtN -----END PGP SIGNATURE----- --gvRjlsUkXaQk0XvPAJJPsJhs5uMO8J7ex--