On 2019/3/2 上午10:29, Chris Murphy wrote:
> On Fri, Mar 1, 2019 at 6:05 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2019/3/2 上午8:20, Chris Murphy wrote:
>>> Problem happens with btrfsprogs 4.19.1
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=202717
>>>
>>> That bug report includes the trace in user space; but I've also
>>> processed the resulting coredump file with gdb and attached that to
>>> the bug report.
>>>
>>> Before using --clear-space-cache v1, btrfs scrub and btrfs check came
>>> up clean no errors. Following the crash, I compiled brfsprogs 4.20.2
>>> and ran 'btrfs check' which finds corruption.
>>>
>>> I've taken no further action, and the btrfs check output gives me no
>>> useful plain language information what the next steps are. So I'm just
>>> gonna leave it alone since it's a backup volume anyway.
>>
>> Is the backup volume binary dump of the original fs?
> 
> No. Only btrfs send/receive.
> 
> 
>>
>> I'm interesting why clear space cache v1 doesn't work, to find out that,
>> we need tree dump of the original fs.
> 
> btrfs insp dump-t -t 2 ? Or the whole thing?

extent tree and root tree.
As those are the only trees modified in clear extent tree.

Thanks,
Qu

> 
>>
>> And is the original check done by latest btrfs-progs or v4.19.1?
> 
> The original check is 4.19.1
> The clear cache is 4.19.1
> The subsequent check showing corruption is 4.20.2 but I've found that
> it's the same output for 4.19.1 as well.
>