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.

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