Christoph Anton Mitterer wrote on 2015/11/24 02:53 +0100:
On Tue, 2015-11-24 at 08:46 +0800, Qu Wenruo wrote:
But there are also some other places like line 4411, 4394 and 4387.
Ah of course, I didn't have a look for further places....
$ grep -n "rec->wrong_chunk_type = 1" cmds-check.c
4387: rec->wrong_chunk_type = 1;
4394: rec->wrong_chunk_type = 1;
4411: rec->wrong_chunk_type = 1;
4421: rec->wrong_chunk_type = 1;
So there are still 3 breakpoint needs to add.
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./btrfs...done.
(gdb) break cmds-check.c:4387
Breakpoint 1 at 0x42cf2b: file cmds-check.c, line 4387.
(gdb) break cmds-check.c:4394
Breakpoint 2 at 0x42cf57: file cmds-check.c, line 4394.
(gdb) break cmds-check.c:4411
Breakpoint 3 at 0x42cfa6: file cmds-check.c, line 4411.
(gdb) break cmds-check.c:4421
Breakpoint 4 at 0x42d000: file cmds-check.c, line 4421.
(gdb) run check /dev/mapper/data-b
Starting program: /home/calestyo/bfsck/btrfs-tools-4.3/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".
Checking filesystem on /dev/mapper/data-b
UUID: 250ddae1-7b37-4b22-89e9-4dc5886c810f
checking extents
Breakpoint 1, check_extent_type (rec=0x20a6740) at cmds-check.c:4387
4387 rec->wrong_chunk_type = 1;
(gdb) continue
Continuing.
Breakpoint 1, check_extent_type (rec=0x20a6740) at cmds-check.c:4387
4387 rec->wrong_chunk_type = 1;
(gdb) cont 100
Will ignore next 99 crossings of breakpoint 1. Continuing.
Breakpoint 1, check_extent_type (rec=0x20a9880) at cmds-check.c:4387
4387 rec->wrong_chunk_type = 1;
(gdb) cont 1000
Will ignore next 999 crossings of breakpoint 1. Continuing.
Great, that's the direct cause.
After some quick glance, it seems that extent_record->metadata does not
always reflect the right status of the extent.
I'll dig further to see what's causing the problem.
Thanks for all the debug info, it really helps a lot!
Qu
That goes on for a few millions... until we get the:
bad extent [6619620016128, 6619620032512), type mismatch with chunk
bad extent [6619620032512, 6619620048896), type mismatch with chunk
again.. and the check exits normally with:
checking free space cache
checking fs roots
checking csums
checking root refs
found 5862373889375 bytes used err is 0
total csum bytes: 5715302800
total tree bytes: 9903816704
total fs tree bytes: 2475769856
total extent tree bytes: 938393600
btree space waste bytes: 1072581913
file data blocks allocated: 9170230497280
referenced 9281014861824
btrfs-progs v4.3
[Inferior 1 (process 18130) exited normally]
So it's the one in 4378.
Anything further to do? :)
Chris.
--
This message has been scanned for viruses and
dangerous content by FCNIC, and is
believed to be clean.
--
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
