On 2020/9/22 上午7:48, Qu Wenruo wrote:
> 
> 
> On 2020/9/21 下午7:46, Martin Steigerwald wrote:
>> Qu Wenruo - 21.09.20, 13:14:05 CEST:
>>>>> For the root cause, it should be some older kernel creating the
>>>>> wrong
>>>>> root item size.
>>>>> I can't find the commit but it should be pretty old, as after v5.4
>>>>> we
>>>>> have mandatory write time tree checks, which will reject such write
>>>>> directly.
>>>>
>>>> So eventually I would have to backup the disk and create FS from
>>>> scratch to get rid of the error? Or can I, even if its no subvolume
>>>> involved, find the item affected, copy it somewhere else and then
>>>> write it to the disk again?
>>> That's the theory.
>>>
>>> We can easily rebuild that data reloc tree, since it should be empty
>>> if balance is not running.
>>>
>>> But we don't have it ready at hand in btrfs-progs...
>>>
>>> So you may either want to wait until some quick dirty fixer arrives,
>>> or can start backup right now.
>>> All the data/files shouldn't be affected at all.
>>
>> Hmmm, do you have an idea if and when such a quick dirty fixer would be 
>> available?
> 
> If you need, I guess in 24 hours.

Here you go:
https://github.com/adam900710/btrfs-progs/tree/dirty_fix

You need to compile the btrfs-progs (in fact, you need to compile
btrfs-corrupt-block).
Then execute:
# ./btrfs-corrupt-block -X <device>

It should solve the problem.
If nothing is output, and no crash, then the repair is done.
Or you will see a crash with calltrace, and your on-disk data is untouched.


The root problem turns out to be a false alert.

It's possible to have an old root item, which is smaller than current
root_item.
In that case, current kernel can handle it without problem.

I'll fix the problem in the kernel too to prevent further false alerts.

Thanks,
Qu

> 
>>
>> Also, is it still safe to write to the filesystem? I looked at the disk, 
>> cause I wanted to move some large files over to it to free up some space 
>> on my laptop's internal SSDs.
> 
> Yes. If you want to be extra safe, just don't utilize balance until it's
> fixed.
> 
> Thanks,
> Qu
> 
>>
>> If its still safe to write to the filesystem, I may just wait. I will 
>> refresh the backup of the disk anyway. But if its not safe to write to 
>> it anymore, I would redo the filesystem from scratch. Would give the 
>> added benefit of having everything zstd compressed and I could also go 
>> for XXHASH or what one of the faster of the new checksum algorithms was.
>>
>> Best,
>>
>