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

["Nik." <btrfs@avgustinov.eu>]

2019-04-07 20:45, Chris Murphy:
> 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 do not quite understand where the "bad key ordering" came from, but my 
question why (in my case) it keeps happening only to the btrfs file 
systems? Is it relevant, that all four failed systems have had initially 
ext4 format and were converted to btrfs (with the btrfs-progs used 5-6 
years ago)?

Another question: I am sure that many btrfs users are ready in some 
cases to trade reliability for performance; wouldn't it be interesting 
to introduce a kind of switch/option like the "verify on", used many 
years ago on msdos-systems to ensure that write operations (especially 
on floppy disks) were successful? Just an idea...

My btrfs-restore is still running (since Monday evening, until now about 
50% restored), and I am on a business trip. As soon as it finishes and I 
am back home I will compare with the backup and give more info, but it 
seems that this would need another day or two.

Kind regards,

Nik.
--

> 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.
> 
>