Re: Force remove of broken extent/subvolume? (Crash in btrfs_run_delayed_refs)

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

在 2024/7/26 20:22, Emil.s 写道:
>> As for any bitflip induced errors, it's hard to tell how far it got
>> propagated, this could be the only instance or there could be other
>> items referring to that one too.
>
> Right, yeah that sounds a bit more challenging then I initially thought.
> Maybe it is easier to just rebuild the array after all.
>
> And in regards to Qu's question, that is probably a good idea anyhow.
>
>> - History of the fs
>> - The hardware spec
>
> This has been my personal NAS / home server for quite some time.
> It's basically a mix of just leftover desktop hardware (without ECC memory).
>
> It was a 12 year old Gigabyte H77-D3H motherboard, an Intel i7-2600 CPU
> and 4 DDR3 DIMMs, all of different types and brands.
> The disks are WD red series, and I see now that one of them has over
> 80k power on hours.

I wasn't expecting this, as the normal "memory chip seldom dies" mostly
applies to a much smaller time span, like around 5 years.

>
> I know I did a rebuild about 5 years ago so the FS was probably
> created using Ubuntu server 18.04 (Linux 4.15), which has been
> upgraded to the major LTS versions since then.

And I believe this is where the corruption happened, before any
tree-checker was even introduced.

Thus we didn't catch it early enough and wrote the corrupted data onto
the disk.

> I actually hit this error when I was doing the "final backup" before
> retiring this setup, and it seems it was about time! (Was running
> Ubuntu 22.04 / Linux 5.15)

Thankfully that specific corruption is only on extent tree, you should
still be able to do the backup with it mounted RO, or with "rescue=all"
to be extra safe.

Thanks,
Qu

>
> The Arch setup on the Thinkstation is my workstation where I attempted
> the data recovery.
>
> So due to the legacy hardware and crappy setup I think it's worth
> wasting more time here.
>
> But thanks a lot for the detailed answer, much appreciated!
>
> Best,
> Emil
>
> On Fri, 26 Jul 2024 at 01:19, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>