At 05/06/2017 02:15 AM, Kai Krakow wrote:
Am Fri, 5 May 2017 08:55:10 +0800
schrieb Qu Wenruo <quwen...@cn.fujitsu.com>:

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 <device>
# btrfs-debug-tree -t chunk <device>

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

Reply via email to