From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Tu6-0001uh-Ni for qemu-devel@nongnu.org; Mon, 20 Aug 2012 11:28:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3Tu5-0007EG-Ce for qemu-devel@nongnu.org; Mon, 20 Aug 2012 11:28:34 -0400 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:63951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3Tu5-0007E5-4p for qemu-devel@nongnu.org; Mon, 20 Aug 2012 11:28:33 -0400 Received: by lagz14 with SMTP id z14so3139992lag.4 for ; Mon, 20 Aug 2012 08:28:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20120820140322.GB9290@irqsave.net> References: <1344953651-16622-1-git-send-email-benoit@irqsave.net> <20120820101229.GA2218@irqsave.net> <20120820114207.GA4197@irqsave.net> <20120820140322.GB9290@irqsave.net> Date: Mon, 20 Aug 2012 16:28:31 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC V3 0/9] Quorum disk image corruption resiliency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Beno=EEt_Canet?= Cc: kwolf@redhat.com, =?ISO-8859-1?Q?Beno=EEt_Canet?= , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, anthony@codemonkey.ws, pbonzini@redhat.com, eblake@redhat.com, afaerber@suse.de On Mon, Aug 20, 2012 at 3:03 PM, Beno=C3=AEt Canet wrote: > Le Monday 20 Aug 2012 =C5=95 13:56:53 (+0100), Stefan Hajnoczi a =C3=A9cr= it : >> On Mon, Aug 20, 2012 at 12:42 PM, Beno=C3=AEt Canet wrote: >> > >> > Le Monday 20 Aug 2012 =C5=95 12:24:33 (+0100), Stefan Hajnoczi a =C3= =A9crit : >> >> On Mon, Aug 20, 2012 at 12:23 PM, Stefan Hajnoczi wrote: >> >> > On Mon, Aug 20, 2012 at 11:12 AM, Beno=C3=AEt Canet wrote: >> >> >> Le Tuesday 14 Aug 2012 =C5=95 16:14:02 (+0200), Beno=C3=AEt Canet = a =C3=A9crit : >> >> >>> This patchset create a block driver implementing a quorum using m= qemu disk >> >> >>> images. Writes are mirrored on the m files. >> >> >>> For the reading part the m files are read at the same time and a = vote is >> >> >>> done to determine if a qiov version is present n or more times. I= t then return >> >> >>> this majority version to the upper layers. >> >> >>> When i < n versions of the data are returned by the lower layer t= he >> >> >>> quorum is broken and the read return -EIO. >> >> >>> >> >> >>> The goal of this patchset is to be turned in a QEMU block filter = living just >> >> >>> above raw-*.c and below qcow2/qed when the required infrastructur= e will be done. >> >> >>> >> >> >>> Main use of this feature will be people using NFS appliances whic= h can be >> >> >>> subjected to bitflip errors. >> >> >>> >> >> >>> This patchset can be used to replace blkverify and the out of tre= e blkmirror. >> >> >>> >> >> >>> usage: -drive file=3Dquorum:n/m:image_1.raw:...:image_m.raw,if=3D= virtio,cache=3Dnone >> >> >> >> >> >> stefanha: I am wondering what would be needed to do in order to ha= ve COR and streaming working >> >> >> with quorum.c ? >> >> > >> >> > .bdrv_is_allocated()/.bdrv_co_is_allocated() needs to be supported = by >> >> > block/quorum.c. Have you tried it and found a problem? >> >> >> >> Just want to confirm you are thinking about image streaming on top of >> >> quorum? Or are you thinking about streaming underneath quorum? >> > >> > I am thinking about streaming with quorum on top of a bunch of backing= files. >> > ie: data landing into the higher level backing file living just under = quorum. >> >> If there are backing files then there must be qcow2 or another image >> format on top of quorum: >> >> qcow2 ("virtio0") >> +------ foo.img (file) >> +------ quorum (backing_hd) >> +------- backing_a.img >> +------- backing_b.img >> +------- backing_c.img >> >> .bdrv_is_allocated()/.bdrv_co_is_allocated() must be supported by quorum= . > > This seems like a low hanging fruit. > > Too bad we cannot create new snapshot of quorum file easily without full > block filter support in qemu. > Am I right ? If the snapshot also needs to use quorum then we definitely need more logic during the snapshot creation process than exists today. Stefan