On 2019/1/17 下午6:42, Christian Schneider wrote: >> >> You could try this patch: >> https://patchwork.kernel.org/patch/10738583/ > > 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. Thanks, Qu >> Or go btrfs-restore. > > I already tried a dry run: > btrfs restore -D /dev/md42 / > This is a dry-run, no files are going to be restored > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > parent transid verify failed on 448937984 wanted 68772 found 68770 > parent transid verify failed on 448937984 wanted 68772 found 68770 > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > parent transid verify failed on 450281472 wanted 32623 found 30451 > parent transid verify failed on 450281472 wanted 32623 found 30451 > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > We have looped trying to restore files in <filename> too many times to > be making progress, stopping > > The filenames are actually directories, but as far as I understand, > actually no files can be restored. > > >> I'm more interested in the history of the fs. >> >> Did the fs get created/modified by some older kernel? >> Especially considering you're using Gentoo, and every kernel update >> needs time consuming compile, it may be caused by some older kernel. > > Yes, the filesystem is "older", though I don't really know how old, I > would guess something between 1 and 2 years, and I update kernels every > 1-2 months. Unfortunatelly I can't give better details of creation of > the fs. > > BR, Christian
signature.asc
Description: OpenPGP digital signature
