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. 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] >
signature.asc
Description: OpenPGP digital signature
