qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 00/12] Qorum disk image corruption resiliency


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC 00/12] Qorum disk image corruption resiliency
Date: Thu, 02 Aug 2012 13:14:54 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Benoît Canet <address@hidden> 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 this
> majoritary version to the upper layers.
> When three differents versions of the data are returned by the lower layer the
> qorum 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]