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: Zhi Yong Wu
Subject: Re: [Qemu-devel] [RFC V7 00/11] Quorum block filter
Date: Tue, 22 Jan 2013 03:02:41 +0800

On Tue, Jan 22, 2013 at 2:44 AM, Eric Blake <address@hidden> wrote:
> 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.
thanks for your great explaination.
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>



-- 
Regards,

Zhi Yong Wu



reply via email to

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