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? 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. 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 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
