From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX8W3-0006s8-AL for qemu-devel@nongnu.org; Sat, 20 Feb 2016 09:28:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aX8W0-0007Pi-KX for qemu-devel@nongnu.org; Sat, 20 Feb 2016 09:28:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aX8W0-0007P6-Cs for qemu-devel@nongnu.org; Sat, 20 Feb 2016 09:28:08 -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> From: Max Reitz Message-ID: <56C877F3.3070401@redhat.com> Date: Sat, 20 Feb 2016 15:28:03 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P3u9HNDVJ1deqXNMdXVV68UajIDmRipmM" 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 , Wen Congyang , Changlong Xie , qemu devel , Kevin Wolf , Eric Blake Cc: "Dr. David Alan Gilbert" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P3u9HNDVJ1deqXNMdXVV68UajIDmRipmM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19.02.2016 12:24, Alberto Garcia wrote: > On Fri 19 Feb 2016 09:26:53 AM CET, Wen Congyang = wrote: >=20 >>>> If quorum has two children(A, B). A do flush sucessfully, but B >>>> flush failed. We MUST choice A as winner rather than just pick >>>> anyone of them. Otherwise the filesystem of guest will become >>>> read-only with following errors: >>>> >>>> end_request: I/O error, dev vda, sector 11159960 >>>> Aborting journal on device vda3-8 >>>> EXT4-fs error (device vda3): ext4_journal_start_sb:327: Detected abo= rt journal >>>> EXT4-fs (vda3): Remounting filesystem read-only >>> >>> Hi Xie, >>> >>> Let's see if I'm getting this right: >>> >>> - When Quorum flushes to disk, there's a vote among the return values= of >>> the flush operations of its members, and the one that wins is the o= ne >>> that Quorum returns. >>> >>> - If there's a tie then Quorum choses the first result from the list = of >>> winners. >>> >>> - With your patch you want to give priority to the vote with result =3D= =3D 0 >>> if there's any, so Quorum would return 0 (and succeed). >>> >>> This seems to me like an ad-hoc fix for a particular use case. What >>> if you have 3 members and two of them fail with the same error code? >>> Would you still return 0 or the error code from the other two? >> >> For example: >> children.0 returns 0 >> children.1 returns -EIO >> children.2 returns -EPIPE >> >> In this case, quorum returns -EPIPE now(without this patch). >> >> For example: >> children.0 returns -EPIPE >> children.1 returns -EIO >> children.2 returns 0 >> In this case, quorum returns 0 now. >=20 > My question is: what's the rationale for returning 0 in case a) but not= > in case b)? >=20 > a) > children.0 returns -EPIPE > children.1 returns -EIO > children.2 returns 0 >=20 > b) > children.0 returns -EIO > children.1 returns -EIO > children.2 returns 0 >=20 > In both cases you have one successful flush and two errors. You want to= > return always 0 in case a) and always -EIO in case b). But the only > difference is that in case b) the errors happen to be the same, so why > does that matter? >=20 > That said, I'm not very convinced of the current logics of the Quorum > flush code either, so it's not even a problem with your patch... it > seems to me that the code should follow the same logics as in the > read/write case: if the number of correct flushes >=3D threshold then > return 0, else select the most common error code. I'm not convinced of the logic either, which is why I waited for you to respond to this patch. :-) Intuitively, I'd expect Quorum to return an error if flushing failed for any of the children, because, well, flushing failed. I somehow feel like flushing is different from a read or write operation and therefore ignoring the threshold would be fine here. However, maybe my intuition is just off. 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. Max --P3u9HNDVJ1deqXNMdXVV68UajIDmRipmM 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 iQEcBAEBCAAGBQJWyHfzAAoJEDuxQgLoOKytmogH/2oItWMPzegvGH/BGZVHzF6A XzVNaKpBQdR7Au8Z3nwu40lLsnwGNEjHGNLnHJy+xD1oVhv5ViqxRST+7oEuQIPu AoQHsmI3ycAojjCd2ZGN3kW0Stl5zsusQVYCp2hmchPCxrMHUSA2yA+gRdlSJQy+ zZG2aqe7c5Ojl2PBHg4tKVXkIfK/Vf8xieHsNgBEkcp+8mMd3Q8PYjbJTsws5IYd UcGL+udwwrlujRyp7lHJDibpLmD3cQFI36UjXP+t9BuxbWezG96bwpuKk/JinpVI pL8Pq+ifFUlgKh0lUCav1QXs4AEb3QAyYGUM2hcxJ/rtiZPgr0Kv5kE5TbZYcMc= =70yT -----END PGP SIGNATURE----- --P3u9HNDVJ1deqXNMdXVV68UajIDmRipmM--