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,
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
