Re: [Qemu-devel] [RFC V3 0/9] Quorum disk image corruption resiliency

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Aug 20, 2012 at 3:03 PM, Benoît Canet <benoit.canet@irqsave.net> wrote:
> Le Monday 20 Aug 2012 ŕ 13:56:53 (+0100), Stefan Hajnoczi a écrit :
>> On Mon, Aug 20, 2012 at 12:42 PM, Benoît Canet <benoit.canet@irqsave.net> wrote:
>> >
>> > Le Monday 20 Aug 2012 ŕ 12:24:33 (+0100), Stefan Hajnoczi a écrit :
>> >> On Mon, Aug 20, 2012 at 12:23 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> >> > On Mon, Aug 20, 2012 at 11:12 AM, Benoît Canet <benoit.canet@irqsave.net> wrote:
>> >> >> Le Tuesday 14 Aug 2012 ŕ 16:14:02 (+0200), Benoît Canet a écrit :
>> >> >>> 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. It then return
>> >> >>> this majority version to the upper layers.
>> >> >>> When i < n versions of the data are returned by the lower layer the
>> >> >>> 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 infrastructure will be done.
>> >> >>>
>> >> >>> Main use of this feature will be people using NFS appliances which can be
>> >> >>> subjected to bitflip errors.
>> >> >>>
>> >> >>> This patchset can be used to replace blkverify and the out of tree blkmirror.
>> >> >>>
>> >> >>> usage: -drive file=quorum:n/m:image_1.raw:...:image_m.raw,if=virtio,cache=none
>> >> >>
>> >> >> stefanha: I am wondering what would be needed to do in order to have 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