Re: external harddisk: bogus corrupt leaf error?

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2313 bytes --]



On 2020/9/22 下午4:40, Martin Steigerwald wrote:
> Qu Wenruo - 22.09.20, 04:14:34 CEST:
>> 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.
> 
> Thank you very much for the prompt delivery of that tool.
> 
> No, in case its safe enough to write it would have not been that urgent.

Since I have manually crafted an image with the same situation, and
tested, it should be OK.
> 
> I hope to find time to try it out this evening. Currently in a training.

Another solution is waiting for the kernel patch to arrive.
That one should be 100% safe.

I hope that one can be merged in v5.9-rc cycle.

Thanks,
Qu

> 
> Ciao,
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]