Re: btrfs and ECC RAM

Chris Murphy
2014-01-27T16:42:54Z

On Jan 27, 2014, at 9:08 AM, Calvin Walton <calvin.walton@kepstin.ca> wrote:

> On Fri, 2014-01-24 at 17:45 -0700, Chris Murphy wrote:
>> On Jan 20, 2014, at 9:08 AM, George Mitchell <george@chinilu.com> wrote:
>>
>>> After reading the recent posts on this topic I am beginning to think
>> there is some real confusion between "check sums" and "parity".
>>
>> Yes, I often see conventional raid6 assumed to always be capable of
>> detecting and correcting corruption, not merely the ability to rebuild
>> missing data of known location and length in a stripe (known either
>> due to the drive reporting read error along with LBA; or a physical
>> device becoming unavailable or unresponsive).
>>
>>> But I CAN see how bad RAM could affect parity calculations and
>> resulting data IN THE ABSENCE of protective checksums and cannot help
>> but wonder if THAT is what the original article is describing.
>>
>> Does Btrfs (and I'd presume ZFS) raid5/6 checksum both data and parity
>> chunks? And in the case of raid6 are the two parities separately
>> checksummed?
>
> The checksumming in Btrfs is actually the other way around; the file
> extents and filesystem metadata structures are checksummed before the
> RAID parity is applied. The resulting blocks containing both data and
> checksums are split over multiple drives with parity.

Got it, thanks, that makes sense. Layout wise, I've read it's better for reduced latency if metadata profile is raid1 rather than raid5/6, when data profile is raid 5/6. I'm pretty sure with multiple devices if a metadata profile isn't explicitly stated at mkfs time, that it's assumed to be raid1, which sounds like a good default. With n mirrors, it may one day make sense to have the number of metadata copies scale automatically based on the number of devices (and always could be explicitly set or changed by the user).

Chris Murphy