May I ask for a little technical details, about what happened/was wrong?
I don't know really anything about internal btrfs stuff, but would like
to gain a little insight. Also, if there is a explanation online, where
you can point me to would be nice.
BR, CHristian
Am 17.01.19 um 15:12 schrieb Qu Wenruo:
On 2019/1/17 下午9:54, Christian Schneider wrote:
Do you know, which kernel is needed as base for the patch? Can I apply
it to 4.19 or do I need more recent? If you don't know, I can just try
it out.
My base is v5.0-rc1.
Although I think there shouldn't be too many conflicts for older kernels.
I could apply the patch on 4.19, but compilation failed. So I went
straight to master, where it worked, and I could even mount the fs now.
Your patch also has a positive impact on free space:
df -h /home
Filesystem Size Used Avail Use% Mounted on
/dev/md42 7.3T 1.9T 1.8P 1% /home
1.8PB available space should be enough for the next few years :D
Thank you very much so far!!!
So, for further steps: As far as I understood, no possibility to repair
the fs?
Unfortunately, no possibility.
The corruption of extent tree is pretty nasty.
Your metadata CoW is completely broken.
It really doesn't make much sense to repair, and I don't really believe
the repaired result could be any good.
I just get the data I can and create it new?
Yep.
And just a general tip, for any unexpected power loss, do a btrfs check
--readonly before doing RW mount.
It would help us to detect and locate possible cause of any corruption
before it cause more damage.
Thanks,
Qu
BR, CHristian
