Re: interest in post-mortem examination of a BTRFS system and improving the btrfs-code?

[Chris Murphy <lists@colorremedies.com>]

On Sun, Apr 7, 2019 at 1:42 AM Nik. <btrfs@avgustinov.eu> wrote:
> 2019-04-07 01:18, Qu Wenruo:

> > You have 2 bits flipped just in one tree block!
> >
> If the data-tree structures alone have so many bits flipped, how much
> flipped bits are to be expected in the data itself? What should a normal
> btrfs user do in order to prevent such disasters?

I think the corruption in your case is inferred by Btrfs only by bad
key ordering, not csum failure for the leaf? I can't tell for sure
from the error, but I don't see a csum complaint.

I'd expect a RAM caused corruption could affect a metadata leaf data,
followed by csum computation. Therefore no csum failure on subsequent
read. Whereas if the corruption is storage stack related, we'd see a
csum error on subsequent read.

Once there's corruption in a block address, the corruption can
propagate into anything else that depends on that block address even
if there isn't another corruption event. So one event, multiple
corruptions.


> And another thing: if I am getting it right, it should have been more
> reliable/appropriate to let btrfs manage the five disks behind the md0
> with a raid1 profile instead binding them in a RAID5 and "giving" just a
> single device to btrfs.

Not necessarily. If corruption happens early enough, it gets baked
into all copies of the metadata.


-- 
Chris Murphy