On 2019/4/12 下午7:38, Nik. wrote: > > > 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. It's based on v4.20 kernel I think. I should refresh the patchset on latest branch before re-sending it to the mail list. > 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"? Oh, that's will be problem. Kernel config is done by "make menuconfig", but if you're not familiar with that, you can easily get a kernel which can't even boot. So just forget this, it's not risky, but very time consuming for end users, too many things need to be learned. Thanks, Qu > 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] >>> >>
Attachment:
signature.asc
Description: OpenPGP digital signature
