Re: external harddisk: bogus corrupt leaf error?

[Martin Steigerwald <martin@lichtvoll.de>]

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.

I hope to find time to try it out this evening. Currently in a training.

Ciao,
-- 
Martin