Hi Christoph,

Since I'm still digging the unexpected corruption (although without much
progress yet), would you please describe how the corruption happens?

In my current investigation, btrfs is indeed bullet-proof, (unlike my
original assumption) using newer dm-log-writes tool.

But free space cache file (v1 free space cache) is not CoW protected so
it's vulnerable against power loss.

So my current assumption is, there are at least 2 power loss happens
during the problem.

The 1st power loss caused free space cache corrupted but not detected by
its checksum, and btrfs used the corrupted free space cache to allocate
tree blocks.

And then 2nd power loss happened. Since new allocated tree blocks can
overwrite existing tree blocks, it breaks metadata CoW of btrfs, and
leads the final corruption.

Would you please provide some detailed info about the corruption?

Thanks,
Qu

On 2018年02月23日 03:21, Christoph Anton Mitterer wrote:
> Am 22. Februar 2018 04:57:53 MEZ schrieb Qu Wenruo <quwenruo.btrfs@gmx.com>:
>>
>>
>> On 2018年02月22日 10:56, Christoph Anton Mitterer wrote:
>>> Just one last for today... I did a quick run with the byte nr from
>> the last mail... See screenshot
>>>
>>> It still gives these mapping errors... But does seem to write
>> files...
>>
>>From your previous picture, it seems that FS_TREE is your primary
>> subvolume, and 257 would be your snapshot.
>>
>> And for that block which can't be mapped, it seems to be a corruption
>> and it's really too large.
>>
>> So ignoring it wouldn't be a problem.
>>
>> And just keep btrfs-store running to see what it salvaged?
>>
>>>
>>> But these mapping errors... Wtf?! 
>>>
>>>
>>> Thanks and until tomorrow.
>>>
>>> Chris
>>>
>>> Oh and in my panic (I still fear that my main data fs, which is on
>> other hard disks could be affected by that strange bug, too, and have
>> no idea how to verify they are not) I forgot: you are from China,
>> aren't you? So a blessed happy new year. :-)
>>
>> Happy new year too.
>>
>> Thanks,
>> Qu
>>
>>>
> 
> Hey
> 
> Have you written more after the mail below?  Cause my normal email account ran full and I cannot recover that right now with my computer.
> 
> Anyway... I tried now the restore and it seems to give back some data (haven't looked at it yet)... I also made a dd copy of the whole fs image to another freshly crafted btrfs fs (as an image file).
> 
> That seemed to work well, but when I differs that image with the original, new csum errors of that file were found. (see attached image)
> 
> Could that be a pointer to some hardware defect? Perhaps the memory? Though I did do an extensive memtest86+ a while ago.
> 
> And that could be the reason for the corruption in the first place...
> 
> Thanks,
> Chris.
>