Re: btrfsck lowmem mode shows corruptions
At 05/06/2017 02:15 AM, Kai Krakow wrote: Am Fri, 5 May 2017 08:55:10 +0800 schrieb Qu Wenruo: At 05/05/2017 01:29 AM, Kai Krakow wrote: Hello! Since I saw a few kernel freezes lately (due to experimenting with ck-sources) including some filesystem-related backtraces, I booted my rescue system to check my btrfs filesystem. Luckily, it showed no problems. It said, everything's fine. But I also thought: Okay, let's try lowmem mode. And that showed a frightening long list of extent corruptions und unreferenced chunks. Should I worry? Thanks for trying lowmem mode. Would you please provide the version of btrfs-progs? Sorry... I realized it myself the moment I hit the "send" button. Here it is: # btrfs version btrfs-progs v4.10.2 # uname -a Linux jupiter 4.10.13-ck #2 SMP PREEMPT Thu May 4 23:44:09 CEST 2017 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux IIRC "ERROR: data extent[96316809216 2097152] backref lost" bug has been fixed in recent release. Is there a patch I could apply? That's strange, btrfs-progs v4.10.2 has already shipped the fix: ad60ed92d1e0edca2769754c3a50129571a0e49d btrfs-progs: check: lowmem, fix false alert about backref lost for SHARED_DATA_REF Then it's a another bug now. And for reference, would you please provide the tree dump of your chunk and device tree? This can be done by running: # btrfs-debug-tree -t device # btrfs-debug-tree -t chunk I'll attach those... I'd like to note that between the OP and these dumps, I scrubbed and rebalanced the hole device. I think that would scramble up some numbers. Also I took the dumps while the fs was online. Online is not a big problem. But rebalance really changed the number, making it quite hard to use the dump to match with previous check error output. I'll try to make a script to filter the output, but first several chunk matches with its dev extent tree. So I'd better digging the lowmem check code to find the problem. Thanks for the report anyway, Qu If you want me to do clean dumps of the offline device without intermediate fs processing, let me know. Thanks, Kai And this 2 dump only contains the btrfs chunk mapping info, so nothing sensitive is contained. Thanks, Qu PS: The freezes seem to be related to bfq, switching to deadline solved these. Full log attached, here's an excerpt: ---8<--- checking extents ERROR: chunk[256 4324327424) stripe 0 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 1 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 2 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 0 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 1 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 2 did not find the related dev extent [...] ERROR: device extent[1, 1094713344, 1073741824] did not find the related chunk ERROR: device extent[1, 2168455168, 1073741824] did not find the related chunk ERROR: device extent[1, 3242196992, 1073741824] did not find the related chunk [...] ERROR: device extent[2, 608854605824, 1073741824] did not find the related chunk ERROR: device extent[2, 609928347648, 1073741824] did not find the related chunk ERROR: device extent[2, 611002089472, 1073741824] did not find the related chunk [...] ERROR: device extent[3, 64433946624, 1073741824] did not find the related chunk ERROR: device extent[3, 65507688448, 1073741824] did not find the related chunk ERROR: device extent[3, 66581430272, 1073741824] did not find the related chunk [...] ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[686074396672 13737984] backref lost ERROR: data extent[686074396672 13737984] backref lost ERROR: data extent[686074396672 13737984] backref lost [...] ERROR: errors found in extent allocation tree or chunk allocation checking free space cache checking fs roots ERROR: errors found in fs roots Checking filesystem on /dev/disk/by-label/system UUID: bc201ce5-8f2b-4263-995a-6641e89d4c88 found 1960075935744 bytes used, error(s) found total csum bytes: 1673537040 total tree bytes: 4899094528 total fs tree bytes: 2793914368 total extent tree bytes: 190398464 btree space waste bytes: 871743708 file data blocks allocated: 6907169177600 referenced 1979268648960 -- 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 -- 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
Re: btrfsck lowmem mode shows corruptions
Am Fri, 5 May 2017 08:55:10 +0800 schrieb Qu Wenruo: > At 05/05/2017 01:29 AM, Kai Krakow wrote: > > Hello! > > > > Since I saw a few kernel freezes lately (due to experimenting with > > ck-sources) including some filesystem-related backtraces, I booted > > my rescue system to check my btrfs filesystem. > > > > Luckily, it showed no problems. It said, everything's fine. But I > > also thought: Okay, let's try lowmem mode. And that showed a > > frightening long list of extent corruptions und unreferenced > > chunks. Should I worry? > > Thanks for trying lowmem mode. > > Would you please provide the version of btrfs-progs? Sorry... I realized it myself the moment I hit the "send" button. Here it is: # btrfs version btrfs-progs v4.10.2 # uname -a Linux jupiter 4.10.13-ck #2 SMP PREEMPT Thu May 4 23:44:09 CEST 2017 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux > IIRC "ERROR: data extent[96316809216 2097152] backref lost" bug has > been fixed in recent release. Is there a patch I could apply? > And for reference, would you please provide the tree dump of your > chunk and device tree? > > This can be done by running: > # btrfs-debug-tree -t device > # btrfs-debug-tree -t chunk I'll attach those... I'd like to note that between the OP and these dumps, I scrubbed and rebalanced the hole device. I think that would scramble up some numbers. Also I took the dumps while the fs was online. If you want me to do clean dumps of the offline device without intermediate fs processing, let me know. Thanks, Kai > And this 2 dump only contains the btrfs chunk mapping info, so > nothing sensitive is contained. > > Thanks, > Qu > > > > PS: The freezes seem to be related to bfq, switching to deadline > > solved these. > > > > Full log attached, here's an excerpt: > > > > ---8<--- > > > > checking extents > > ERROR: chunk[256 4324327424) stripe 0 did not find the related dev > > extent ERROR: chunk[256 4324327424) stripe 1 did not find the > > related dev extent ERROR: chunk[256 4324327424) stripe 2 did not > > find the related dev extent ERROR: chunk[256 7545552896) stripe 0 > > did not find the related dev extent ERROR: chunk[256 7545552896) > > stripe 1 did not find the related dev extent ERROR: chunk[256 > > 7545552896) stripe 2 did not find the related dev extent [...] > > ERROR: device extent[1, 1094713344, 1073741824] did not find the > > related chunk ERROR: device extent[1, 2168455168, 1073741824] did > > not find the related chunk ERROR: device extent[1, 3242196992, > > 1073741824] did not find the related chunk [...] > > ERROR: device extent[2, 608854605824, 1073741824] did not find the > > related chunk ERROR: device extent[2, 609928347648, 1073741824] did > > not find the related chunk ERROR: device extent[2, 611002089472, > > 1073741824] did not find the related chunk [...] > > ERROR: device extent[3, 64433946624, 1073741824] did not find the > > related chunk ERROR: device extent[3, 65507688448, 1073741824] did > > not find the related chunk ERROR: device extent[3, 66581430272, > > 1073741824] did not find the related chunk [...] > > ERROR: data extent[96316809216 2097152] backref lost > > ERROR: data extent[96316809216 2097152] backref lost > > ERROR: data extent[96316809216 2097152] backref lost > > ERROR: data extent[686074396672 13737984] backref lost > > ERROR: data extent[686074396672 13737984] backref lost > > ERROR: data extent[686074396672 13737984] backref lost > > [...] > > ERROR: errors found in extent allocation tree or chunk allocation > > checking free space cache > > checking fs roots > > ERROR: errors found in fs roots > > Checking filesystem on /dev/disk/by-label/system > > UUID: bc201ce5-8f2b-4263-995a-6641e89d4c88 > > found 1960075935744 bytes used, error(s) found > > total csum bytes: 1673537040 > > total tree bytes: 4899094528 > > total fs tree bytes: 2793914368 > > total extent tree bytes: 190398464 > > btree space waste bytes: 871743708 > > file data blocks allocated: 6907169177600 > > referenced 1979268648960 > > > > > -- > 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 > -- Regards, Kai Replies to list-only preferred. chunk-tree.txt.gz Description: application/gzip device-tree.txt.gz Description: application/gzip
Re: btrfsck lowmem mode shows corruptions
At 05/05/2017 01:29 AM, Kai Krakow wrote: Hello! Since I saw a few kernel freezes lately (due to experimenting with ck-sources) including some filesystem-related backtraces, I booted my rescue system to check my btrfs filesystem. Luckily, it showed no problems. It said, everything's fine. But I also thought: Okay, let's try lowmem mode. And that showed a frightening long list of extent corruptions und unreferenced chunks. Should I worry? Thanks for trying lowmem mode. Would you please provide the version of btrfs-progs? IIRC "ERROR: data extent[96316809216 2097152] backref lost" bug has been fixed in recent release. And for reference, would you please provide the tree dump of your chunk and device tree? This can be done by running: # btrfs-debug-tree -t device # btrfs-debug-tree -t chunk And this 2 dump only contains the btrfs chunk mapping info, so nothing sensitive is contained. Thanks, Qu PS: The freezes seem to be related to bfq, switching to deadline solved these. Full log attached, here's an excerpt: ---8<--- checking extents ERROR: chunk[256 4324327424) stripe 0 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 1 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 2 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 0 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 1 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 2 did not find the related dev extent [...] ERROR: device extent[1, 1094713344, 1073741824] did not find the related chunk ERROR: device extent[1, 2168455168, 1073741824] did not find the related chunk ERROR: device extent[1, 3242196992, 1073741824] did not find the related chunk [...] ERROR: device extent[2, 608854605824, 1073741824] did not find the related chunk ERROR: device extent[2, 609928347648, 1073741824] did not find the related chunk ERROR: device extent[2, 611002089472, 1073741824] did not find the related chunk [...] ERROR: device extent[3, 64433946624, 1073741824] did not find the related chunk ERROR: device extent[3, 65507688448, 1073741824] did not find the related chunk ERROR: device extent[3, 66581430272, 1073741824] did not find the related chunk [...] ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[686074396672 13737984] backref lost ERROR: data extent[686074396672 13737984] backref lost ERROR: data extent[686074396672 13737984] backref lost [...] ERROR: errors found in extent allocation tree or chunk allocation checking free space cache checking fs roots ERROR: errors found in fs roots Checking filesystem on /dev/disk/by-label/system UUID: bc201ce5-8f2b-4263-995a-6641e89d4c88 found 1960075935744 bytes used, error(s) found total csum bytes: 1673537040 total tree bytes: 4899094528 total fs tree bytes: 2793914368 total extent tree bytes: 190398464 btree space waste bytes: 871743708 file data blocks allocated: 6907169177600 referenced 1979268648960 -- 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
btrfsck lowmem mode shows corruptions
Hello! Since I saw a few kernel freezes lately (due to experimenting with ck-sources) including some filesystem-related backtraces, I booted my rescue system to check my btrfs filesystem. Luckily, it showed no problems. It said, everything's fine. But I also thought: Okay, let's try lowmem mode. And that showed a frightening long list of extent corruptions und unreferenced chunks. Should I worry? PS: The freezes seem to be related to bfq, switching to deadline solved these. Full log attached, here's an excerpt: ---8<--- checking extents ERROR: chunk[256 4324327424) stripe 0 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 1 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 2 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 0 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 1 did not find the related dev extent ERROR: chunk[256 7545552896) stripe 2 did not find the related dev extent [...] ERROR: device extent[1, 1094713344, 1073741824] did not find the related chunk ERROR: device extent[1, 2168455168, 1073741824] did not find the related chunk ERROR: device extent[1, 3242196992, 1073741824] did not find the related chunk [...] ERROR: device extent[2, 608854605824, 1073741824] did not find the related chunk ERROR: device extent[2, 609928347648, 1073741824] did not find the related chunk ERROR: device extent[2, 611002089472, 1073741824] did not find the related chunk [...] ERROR: device extent[3, 64433946624, 1073741824] did not find the related chunk ERROR: device extent[3, 65507688448, 1073741824] did not find the related chunk ERROR: device extent[3, 66581430272, 1073741824] did not find the related chunk [...] ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[96316809216 2097152] backref lost ERROR: data extent[686074396672 13737984] backref lost ERROR: data extent[686074396672 13737984] backref lost ERROR: data extent[686074396672 13737984] backref lost [...] ERROR: errors found in extent allocation tree or chunk allocation checking free space cache checking fs roots ERROR: errors found in fs roots Checking filesystem on /dev/disk/by-label/system UUID: bc201ce5-8f2b-4263-995a-6641e89d4c88 found 1960075935744 bytes used, error(s) found total csum bytes: 1673537040 total tree bytes: 4899094528 total fs tree bytes: 2793914368 total extent tree bytes: 190398464 btree space waste bytes: 871743708 file data blocks allocated: 6907169177600 referenced 1979268648960 -- Regards, Kai Replies to list-only preferred. lowmem.txt.gz Description: application/gzip