qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC V7 00/11] Quorum block filter


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC V7 00/11] Quorum block filter
Date: Mon, 21 Jan 2013 11:44:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 01/21/2013 11:35 AM, Zhi Yong Wu wrote:
> On Mon, Jan 21, 2013 at 10:25 PM, Benoît Canet <address@hidden> wrote:
>>> I don't know if the following case can be handled correctly.
>>> For example, quorum:2/3:image1.raw:image2.raw:image3.raw
>>> Let us assume that some data in image2.raw and image3.raw get
>>> corrupted, and the two images are now completely identical; while
>>> image1.raw doesn't get corrupted. In this case, how will your vote
>>> method know if which image gets corrupted and which image doesn't?
>>
>> It won't the reads will be corrupted on this sector.
> sorry, i haven't got what it means, can you say standard english?:)
> 
> e.g, there is one words on image1.raw such as "USA is one great
> country", but due to network bitflip, it is changed to "UK is one
> greate country" on image2.raw and image3.raw.
> the reads will not be corrupted on these sectors on different images,
> how will quorum block filter determine which images are correct while
> which aren't?
> 
>> That's why one must set each image on a different filer to avoid identical
>> corruptions.
> Since each image locates on different filer, you can't also make 100%
> sure to avoid identical corruptions.

Corruption is corruption, no matter how it happens.  If two of the three
images in a quorum are corrupted in the exact same manner, you have lost
data.  But the reason to use a quorum is that the probability of the
majority of the images getting the exact same corruption, especially
when the various images in the quorum all come from different storage
filers, is so small that you need not worry about it; or else you are
worried about it, but then you need something stronger and slower than
just a quorum, such as a cryptographic checksum of every sector rather
than just a majority rule.  Compare this to how ddrescue works - their
advice is to burn at least two copies of any important CD or DVD; even
if you start to get read failures in one or even both of the images, the
probability of getting identical read failures in identical sectors on
both disks is so slim that you can still reconstruct the original iso in
a staggeringly high percentage of cases.

-- 
Eric Blake   eblake redhat com    +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]