Re: [Xen-users] Cheap IOMMU hardware and ECC support importance

[lee <lee@xxxxxxxxxxxxxxx>]

Gordan Bobic <gordan@xxxxxxxxxx> writes:

>> On 2014-07-09 02:13, lee wrote:
>
>>> For domU, you put it on whatever volume the rest of the domU
>>> filesystems are on.
>>
>> Without swap partitions?
>
> No, partition the domU virtual disk inside the domU in any
> way you like, including swap partitions.

How would I have a virtual disk?  Do you mean I should put the VM images
into a file residing on a ZFS file system of dom0?

>>> How often does your RAID controller scrub the array to check for
>>> errors? If it finds that in a particular RAID5 stripe the data doesn't
>>> match the parity, but none of the disks return an error, does it trust
>>> that the data is correct or the parity is correct? If parity, which
>>> combination of data blocks does it assume are correct, and which block
>>> needs to be repaired? ZFS can recover from this even with n+1
>>> redundancy because each data stripe has a checksum independent of the
>>> parity, so it is possible to establish which combination of surviving
>>> data+parity blocks is the correct one, and which blocks need to be
>>> re-built.
>>
>> Interesting question --- are you saying the hardware RAID controller
>> has
>> no way of knowing which data is good because it uses parity information
>> merely to be able to reconstruct data when a part of that data is not
>> available anymore while ZFS uses checksums on each part of the data
>> which not only allows it to reconstruct the data when a part of it is
>> unavailable, but it also can know which part of the data is good
>> because
>> it assumes that the data for which the checksums match is good?
>
> Yes, that is exactly what I'm saying.

So I see why you're saying that RAID isn't sufficient anymore.

> The entire premise is wrong - you cannnot meaningfully gain information
> from a test without understanding the test.

That's why I'm saying it's not such a great example.  You need to
understand what it attempts to show to make you understand before it
shows it.

> Or you could encrypt your data before becking it up. If you use
> something like encfs, you  can back up the underlying encrypted
> data rather than the unencrypted data. That way it doesn't matter
> how they store it.

I'd have to make a huge tar archive or something of my data and encrypt
that with gpg before uploading it.  That isn't really feasible.

>>>>>>>> What is the actual rate of data corruption or loss prevented or
>>>>>>>> corrected by ZFS due to its checksumming in daily usage?
>>>
>>>> How much data can you, in daily
>>>> usage, read/write from/to a ZFS file system with how many errors
>>>> detected and corrected only due to the checksumming ZFS does?
>>>
>>> See above. Depending on disk make/model, potentially as high as one
>>> per 100GB on some disk models.
>>
>> Potentially, theoretically, no ZFS involved ...
>>
>> You are using ZFS, so do you see this one error per 100GB?  Or what do
>> you see?
>
> It's not something I log/graph. Maybe I should add it to my zabbix
> setup...

I'd find it interesting.  There are studies about disk failures and ways
of loosing data.  Gathering such information could start a study which
shows not only all kinds of errors but, more importantly, how and that
the data is kept save nonetheless, and simply by using ZFS.


-- 
Knowledge is volatile and fluid.  Software is power.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users