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: Eric Blake
Subject: Re: [Qemu-devel] [RFC 00/12] Qorum disk image corruption resiliency
Date: Thu, 02 Aug 2012 07:17:35 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

On 08/02/2012 04:16 AM, Benoît Canet wrote:
> This patchset create a block driver implementing a qorum using three qemu disk

s/qorum/quorum/g throughout the series, including subject line

> 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

s/majoritary/majority/

> majoritary version to the upper layers.
> When three differents versions of the data are returned by the lower layer the

s/differents/different/

> 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.
> 
> usage: -drive file=qorum:image1.raw:image2.raw:image3.raw,if=virtio,cache=none

How does this fit with snapshots?  Does a snapshot of a quorum require
passing in three filenames, one for each of the three sources?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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