2019-04-12 12:50, Qu Wenruo:
On 2019/4/12 下午6:44, Nik. wrote:
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?
That's the only remaining thing you need.
Ok, the "git clone ..." just finished, but in your earlier mail you
spoke about kernel 5.1/5.2, and the readme of the above repository is
talking about "Linux kernel release 4.x"? Since building the kernel is
not a "minute" task (especially when building on atom processor), I
would like to double check the steps to be done.
Until now:
$ git clone https://github.com/adam900710/linux.git
$ git checkout --track origin/rescue_options
What next? No autogen, no configure. ... The Readme refers to
"Documentation/process/changes.rst", so am I going to follow its section
"Configuring the kernel"?
If there is another description of the steps to be taken somewhere -
please provide a link.
Best,
Nik.
In fact, I didn't consider the size of the fs, and for that large fs,
rescue mount option should be the first choice before btrfs-restore.
Thanks,
Qu
Something else, which is risky and should not be tried
on a production system?
Kind regards,
Nik.
--
[snip]
