From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwzvK-0006Yt-7x for qemu-devel@nongnu.org; Thu, 02 Aug 2012 14:15:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwzvF-0001or-Tv for qemu-devel@nongnu.org; Thu, 02 Aug 2012 14:15:02 -0400 Received: from mail-qa0-f45.google.com ([209.85.216.45]:61610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwzvF-0001oh-PU for qemu-devel@nongnu.org; Thu, 02 Aug 2012 14:14:57 -0400 Received: by qaeb19 with SMTP id b19so3254346qae.4 for ; Thu, 02 Aug 2012 11:14:57 -0700 (PDT) From: Anthony Liguori In-Reply-To: <1343902604-13981-1-git-send-email-benoit@irqsave.net> References: <1343902604-13981-1-git-send-email-benoit@irqsave.net> Date: Thu, 02 Aug 2012 13:14:54 -0500 Message-ID: <87y5lxi2jl.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 00/12] Qorum disk image corruption resiliency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Beno=C3=AEt?= Canet , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@linux.vnet.ibm.com, =?utf-8?Q?Beno=C3=AEt?= Canet Beno=C3=AEt Canet writes: > This patchset create a block driver implementing a qorum using three qemu= disk > images. Writes are mirrored on the three files. > For the reading part the three files are read at the same time and a vote= is > done to determine which is the majoritary qiov version. It then return th= is > majoritary version to the upper layers. > When three differents versions of the data are returned by the lower laye= r the > qorum is broken and the read return -EIO. > > The goal of this patchset is to be turned in a QEMU block filter living j= ust > above raw-*.c and below qcow2/qed when the required infrastructure will b= e done. > > Main use of this feature will be people using NFS appliances which can be > subjected to bitflip errors. I'm not entirely sure I understand the use-case all that well. Wouldn't the more typical approach be RAID-5 and the use of parity instead of relying on voting? Quorum doesn't work well with an odd number of disks whereas RAID-5 does. You also get significantly more usable disk space with RAID-5 then with voting. Regards, Anthony Liguori