On Sun, Apr 7, 2019 at 1:42 AM Nik. <bt...@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
