2019-04-08 23:22, Nik.:
2019-04-08 15:09, Qu Wenruo:
Unfortunately, I didn't receive the last mail from Nik.
So I'm using the content from lore.kernel.org.
[122293.101782] BTRFS critical (device md0): corrupt leaf: root=1
block=1894009225216 slot=82, bad key order, prev (2034321682432 168
262144) current (2034318143488 168 962560)
Root=1 means it's root tree, 168 means EXTENT_ITEM, which should only
occur in extent tree, not in root tree.
This means either the leaf owner, or some tree blocks get totally
screwed up.
This is not easy to fix, if possible.
Would you please try this kernel branch and mount it with
"rescue=skip_bg,ro"?
https://github.com/adam900710/linux/tree/rescue_options
I think that's the last method. Before that, you could try
btrfs-restore, which is purely user-space and should be easier to setup
than custom kernel.
Thanks,
Qu
Tried "btrfs restore -vsxmi ..." (it did not work before my first
email), it is processing for at least 6 hours until now. It seems that
despite many error messages files are getting restored. As soon as it
finishes will check what is the result and give feedback. Will also
test the mentioned kernel branch.
After almost four days only about 120 GB of my initially 3.7TB of free
space remain free, and the restore is still working (how about
introducing a "progress" switch?)... I guess that due to the option "-s"
and the lack of deduplication the snapshots are going to fill all the
space without reaching the "end" of the file restoring system.
Until now I still did not have chance (and time) to compare the restored
with backups, but at this point I would like to ask you: what else would
you like to know|try|do? Should I try the mentioned above kernel and its
rescue options? Something else, which is risky and should not be tried
on a production system?
Kind regards,
Nik.
--
[snip]
