Re: How to recover a filesystem without formatting nor using the btrfs check command.

[none <ytrezq@sdf-eu.org>]

Le 2017-01-03 07:11, Qu Wenruo a écrit :
>> 
>> Hello, what’s the status of my report since last October ?
>> 
>> thanks,
>> 
>> 
> Sorry for the late reply.
> 
> I tried your image but...
> It's so slow, no matter the mode I'm using.
> 
> So I'm not sure if it's a deadlock since lowmem mode still takes
> several minuts and just output the same output.
Anyway, I got the lowmem mode finishing. But it didn’t solved my 
problem. I have a core i7‑6700k ᴄᴘᴜ
> The fs contains SOOOOOOOOO many reflinks and I can hardly determine if
> it's normal or deadlock.
> 
Yes, but most those reflinks are used only by a small number of sparse 
file whose content are made of 0 bits (they still represent several 
hundreds of Gb data). If those files can be deleted, then I should be 
able to btrfs the disk normally. (the problem is I can’t do it because 
of filesystem corruption)

I don’t know how much they are, but I think the number is high enough to 
make btrfscking the disk as hard as breaking encryption.

> Considering btrfs check original mode is using list to iteration
> backrefs, it can be very very slow, maybe O(n^3)~O(n^4).
> 
> And considering the number of reflinks, it can be longer than your
> assumption (maybe longer than 48 hours).

I tried running it and even after a week nothing is finished. I never 
assumed anything.

> Just try xfstests generic/175, and see how slow btrfs check is.
> 
> 
> And since your fs tree is super big, normal btrfs-debug-tree output
> will be over several GBs for debugging, this also makes things quite
> nasty to debug manually.
But most of the virtual space is used by only a small number of very 
large files which I agree to delete.

> IMHO we only have 2 remaining methods to fix your fs:
> 1) Rework current backref structure.
>    Use rb-tree other than list to iteration.
> 2) Introduce --init-extent-tree in lowmem mode.
> 
> Neither way it's a quick fix.
> And I'm trying to implement the 2nd method first, but it may takes a
> lot of time.
> (I still have a lot of other btrfs development to do, sorry)
> 
> I'd suggest you to rebuild the fs, considering the time we need to fix 
> it.
which I can’t, looks like it will takes some months to get a rce 
vulnerability in git to get fixed (before corrupting the filesystem, I 
saw ᴄᴠᴇ‑2016‑2315 was fixed incorrectly on GitHub servers).

As soon as I get access to my previous work data, I will be able to 
trace the root cause in ~1‒5 hours.
> Thanks,
> Qu
regards,