On 2018年06月23日 05:20, Daniel Underwood wrote: > Thanks for the help, I started `check --repair --init-extent-tree` > right around a week ago as a last effort before restoring from backup. > Unfortunately, that command is still running. It does seem to be using > about half of the system's RAM (8 of 16GB) and 100% load on a single > core. Is this type of run time expected for an 8TB drive?
It depends. Since it will iterate the whole disk serval times, it takes a long time, especially if you have a lot of used space of that 8T drive. To determine if it's doing dead loop, we need to verify the output is not duplicating itself. > The byte > numbers it's referencing seem to be a bit odd to me as they're larger > than the number of bytes on the drive. Completely valid. As btrfs is using logical address, it's completely valid that logical bytenr is larger than your device if you have balanced the device several times before. > Here's the head and tail of the > current run (separated by -----) if that's indicative of progress: > > btrfs unable to find ref byte nr 49673574858752 parent 0 root 1 owner > 2 offset 0 > btrfs unable to find ref byte nr 49673719529472 parent 0 root 1 owner > 1 offset 1 > btrfs unable to find ref byte nr 62243448012800 parent 0 root 1 owner > 0 offset 1 > btrfs unable to find ref byte nr 49673575120896 parent 0 root 1 owner > 1 offset 1 > btrfs unable to find ref byte nr 49673575251968 parent 0 root 1 owner > 0 offset 1 > checking extents > ref mismatch on [49218307751936 67108864] extent item 0, found 1 > data backref 49218307751936 root 5 owner 1359193 offset 536870912 > num_refs 0 not found in extent tree > incorrect local backref count on 49218307751936 root 5 owner 1359193 > offset 536870912 found 1 wanted 0 back 0x5583559bd790 > backpointer mismatch on [49218307751936 67108864] > ----------------- > data backref 49230998138880 root 5 owner 1409678 offset 7408779264 > num_refs 0 not found in extent tree > incorrect local backref count on 49230998138880 root 5 owner 1409678 > offset 7408779264 found 1 wanted 0 back 0x5583b95f0e20 > backpointer mismatch on [49230998138880 16384] > adding new data backref on 49230998138880 root 5 owner 1409678 offset > 7408779264 found 1 > Repaired extent references for 49230998138880 > ref mismatch on [49230998155264 16384] extent item 0, found 1 > data backref 49230998155264 root 5 owner 669291 offset 3905650688 > num_refs 0 not found in extent tree > incorrect local backref count on 49230998155264 root 5 owner 669291 > offset 3905650688 found 1 wanted 0 back 0x5582efb12930 > backpointer mismatch on [49230998155264 16384] > adding new data backref on 49230998155264 root 5 owner 669291 offset > 3905650688 found 1 Looks it's processing. But it's better to keep all the output and verify the same section of bytenr doesn't re-appear too many times. > > Thanks, > Daniel > > > On Thu, Jun 14, 2018 at 10:43 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >> From the output, specially the lowmem mode output since original mode >> handles extent tree corruption poorly and aborted, it's your extent tree >> corrupted and causing the bug. >> >> Thus, you should be able to mount the fs RO and copy all the data back >> without much hassle. >> Just need to pay attention for csum error. >> >> And considering how many extent tree corruption, I don't think it's a >> good idea to manually fix the fs. >> >> The last chance is, to try --repair --init-extent-tree as your last >> chance, if you still want to salvage the filesystem. >> The lowmem mode shows no extra bug, thus it's possible for >> --init-extent-tree to re-init extent tree and save the day. >> >> But personally speaking I'm not fully confident of the operation, thus >> it may fail and you may need to use the backup. >> >> BTW, even --init-extent-tree succeeded, you may still need to run btrfs >> check again to check if all the bugs are fixed. >> But at least from the lowmem output, the remaining errors are all fixable. >> >> Thanks, >> Qu > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
signature.asc
Description: OpenPGP digital signature
