On 2020/8/13 下午1:53, Spencer Collyer wrote:
> On Wed, 12 Aug 2020 22:15:23 +0800, Qu Wenruo wrote:
>> On 2020/8/12 下午9:49, Spencer Collyer wrote:
>>> I have just received a 'write time tree block corruption detected'
>>> message on a BTRFS fs I use. As per
>>> https://btrfs.wiki.kernel.org/index.php/Tree-checker it mentions
>>> sending a mail to this mailing list for this case.
>>>
>>> The dmesg output from the error onwards is as follows:
>>>
>>> [17434.620469] BTRFS error (device dm-1): block=13642806624256
>>> write time tree block corruption detected  
>>
>> What's the line before this line?
>>
>> That's the most important line, and it's unfortunately not there...
>>
>> Thanks,
>> Qu
> 
> Oh, didn't realise that. Unfortunately it has gone from the dmesg ring buffer, so I can't go back to it.  If it happens again I'll take a copy of the full dmesg output so I can go back to it.
> 
> The page I mentioned previously (https://btrfs.wiki.kernel.org/index.php/Tree-checker) just mentions to report the error to this mailing list. Might be an idea to expand that line to explain what needs reporting.
> 
> Rereading the linked page, I notice that it says that if it is a write error that is prevented then the fs should still be OK, and you can run 'btrfs check --readonly' to check that. It is 'btrfs check --repair' that it says to not run unless told to by a developer. So I'm going to run the '--readonly' check and if that looks good I'll try re-running the command that caused the failure - does that seem reasonable?

Running btrfs check is always a good idea to ensure nothing is wrong.

Write time tree checker mostly detects the following types of errors:
- Memory bit flip
  Then you'd better to at least run a memtest to ensure your memory is
  fine.

- Btrfs internal bug
  One example is the csum item overlap, which is a bug and soon get
  fixed.

Although you can definitely try the same command, I doubt if it can
reproduce the problem.

But anyway, if you can reproduce the bug, it would definitely be helpful
for us to look into.

Thanks,
Qu

> 
> Thanks for your attention,
> 
> Spencer
>