Hey Qu.
On Sun, 2015-11-22 at 10:04 +0800, Qu Wenruo wrote:
> If any of you can recompile btrfs-progs and use gdb to debug it,
> would
> anyone please to investigate where did the wrong_chunk_type is set?
> It is in the function check_extent_type():
Not 100% what you want... AFAIU, you just want to see whether that line
is reached?
If didn't re-compile but used the btrfs-tools-dbg package, but I guess
that should do.
In the debian version that line seems to be at:
4374
4375 /* Check if the type of extent matches with its chunk */
4376 static void check_extent_type(struct extent_record *rec)
4377 {
...
4419 bg_type = BTRFS_BLOCK_GROUP_METADATA;
4420 if (!(bg_cache->flags & bg_type))
4421 rec->wrong_chunk_type = 1;
4422 }
4423 }
Running:
# gdb btrfs
(gdb) dir /root/btrfs-tools-4.3
Source directories searched: /root/btrfs-tools-4.3:$cdir:$cwd
(gdb) break cmds-check.c:4421
Breakpoint 1 at 0x41d859: file cmds-check.c, line 4421.
(gdb) run check /dev/mapper/data-b
Starting program: /bin/btrfs check /dev/mapper/data-b
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
... in fact reaches that breakpoint:
Breakpoint 1, check_extent_type (rec=rec@entry=0x884290) at cmds-check.c:4423
4423 }
... but the error message ("bad extent [5993525264384, 5993525280768),
type mismatch with chunk") doesn't seem to be printed at that stage...
If I continue, it goes for a while:
Breakpoint 1, check_extent_type (rec=rec@entry=0x884290) at cmds-check.c:4423
4423 }
(gdb) cont 100000
Will ignore next 99999 crossings of breakpoint 1. Continuing.
and so on for at least several million crossings... I then removed the
breakpoint and after a longer while the usual error messages came up.
Does that help?
Chris.
smime.p7s
Description: S/MIME cryptographic signature
