linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk
Date: Wed, 25 Nov 2015 05:16:55 +0100	[thread overview]
Message-ID: <1448425015.21291.142.camel@scientia.net> (raw)
In-Reply-To: <1448422525.21291.131.camel@scientia.net>

[-- Attachment #1: Type: text/plain, Size: 7219 bytes --]

Hey again.

So it seems that data-b is always fine (well at least three times in a
row) and data-old-a always gives errors.

including e.g:
bad extent [3067663679488, 3067663695872), type mismatch with chunk
bad extent [3067663876096, 3067663892480), type mismatch with chunk
bad extent [3067663892480, 3067663908864), type mismatch with chunk
bad extent [3067663908864, 3067663925248), type mismatch with chunk
bad extent [3067669348352, 3067669364736), type mismatch with chunk
bad extent [3067669430272, 3067669446656), type mismatch with chunk
bad extent [3067669659648, 3067669676032), type mismatch with chunk
bad extent [3067669790720, 3067669807104), type mismatch with chunk
bad extent [3067669807104, 3067669823488), type mismatch with chunk
bad extent [3067669823488, 3067669839872), type mismatch with chunk
bad extent [3067669872640, 3067669889024), type mismatch with chunk
bad extent [3067669921792, 3067669938176), type mismatch with chunk
bad extent [3067671805952, 3067671822336), type mismatch with chunk

I've started debugging (everything as before) with:
(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.

Hit a:
Breakpoint 1, check_extent_type (rec=0x1a44130) at cmds-check.c:4387
4387				rec->wrong_chunk_type = 1;
(gdb) bt
#0  check_extent_type (rec=0x1a44130) at cmds-check.c:4387
#1  0x000000000042d6a5 in add_extent_rec (extent_cache=0x7fffffffdf30, parent_key=0x0, parent_gen=0, start=1097665216512, nr=16384, extent_item_refs=1, is_root=0, inc_ref=0, set_checked=0, 
    metadata=0, extent_rec=1, max_size=16384) at cmds-check.c:4576
#2  0x000000000042ecc9 in process_extent_item (root=0x919d20, extent_cache=0x7fffffffdf30, eb=0x1a0edb0, slot=95) at cmds-check.c:5142
#3  0x0000000000430aea in run_next_block (root=0x919d20, bits=0x91e220, bits_nr=1024, last=0x7fffffffdb78, pending=0x7fffffffdf10, seen=0x7fffffffdf20, reada=0x7fffffffdf00, 
    nodes=0x7fffffffdef0, extent_cache=0x7fffffffdf30, chunk_cache=0x7fffffffdf90, dev_cache=0x7fffffffdfa0, block_group_cache=0x7fffffffdf70, dev_extent_cache=0x7fffffffdf40, ri=0x6cef30)
    at cmds-check.c:5960
#4  0x00000000004356c4 in deal_root_from_list (list=0x7fffffffdc00, root=0x919d20, bits=0x91e220, bits_nr=1024, pending=0x7fffffffdf10, seen=0x7fffffffdf20, reada=0x7fffffffdf00, 
    nodes=0x7fffffffdef0, extent_cache=0x7fffffffdf30, chunk_cache=0x7fffffffdf90, dev_cache=0x7fffffffdfa0, block_group_cache=0x7fffffffdf70, dev_extent_cache=0x7fffffffdf40)
    at cmds-check.c:8014
#5  0x0000000000435d91 in check_chunks_and_extents (root=0x919d20) at cmds-check.c:8181
#6  0x0000000000438e2b in cmd_check (argc=1, argv=0x7fffffffe220) at cmds-check.c:9627
#7  0x0000000000409d49 in main (argc=2, argv=0x7fffffffe220) at btrfs.c:252
(gdb) continue
Continuing.

Breakpoint 1, check_extent_type (rec=0x1a44130) at cmds-check.c:4387
4387				rec->wrong_chunk_type = 1;
(gdb) bt
#0  check_extent_type (rec=0x1a44130) at cmds-check.c:4387
#1  0x000000000042d856 in add_tree_backref (extent_cache=0x7fffffffdf30, bytenr=1097665216512, parent=1314162819072, root=0, found_ref=0) at cmds-check.c:4624
#2  0x000000000042ede2 in process_extent_item (root=0x919d20, extent_cache=0x7fffffffdf30, eb=0x1a0edb0, slot=95) at cmds-check.c:5161
#3  0x0000000000430aea in run_next_block (root=0x919d20, bits=0x91e220, bits_nr=1024, last=0x7fffffffdb78, pending=0x7fffffffdf10, seen=0x7fffffffdf20, reada=0x7fffffffdf00, 
    nodes=0x7fffffffdef0, extent_cache=0x7fffffffdf30, chunk_cache=0x7fffffffdf90, dev_cache=0x7fffffffdfa0, block_group_cache=0x7fffffffdf70, dev_extent_cache=0x7fffffffdf40, ri=0x6cef30)
    at cmds-check.c:5960
#4  0x00000000004356c4 in deal_root_from_list (list=0x7fffffffdc00, root=0x919d20, bits=0x91e220, bits_nr=1024, pending=0x7fffffffdf10, seen=0x7fffffffdf20, reada=0x7fffffffdf00, 
    nodes=0x7fffffffdef0, extent_cache=0x7fffffffdf30, chunk_cache=0x7fffffffdf90, dev_cache=0x7fffffffdfa0, block_group_cache=0x7fffffffdf70, dev_extent_cache=0x7fffffffdf40)
    at cmds-check.c:8014
#5  0x0000000000435d91 in check_chunks_and_extents (root=0x919d20) at cmds-check.c:8181
#6  0x0000000000438e2b in cmd_check (argc=1, argv=0x7fffffffe220) at cmds-check.c:9627
#7  0x0000000000409d49 in main (argc=2, argv=0x7fffffffe220) at btrfs.c:252

You've mentioned add_extent_rec() before, but that doesn't seem to
contain bytenr so I cannot break on it.

I tried it with add_tree_backref instead, maybe that's already helpful
for you until you give me further instructions on what to debug:
Breakpoint 5 at 0x42d84a: file cmds-check.c, line 4624.
(gdb) continue 
Continuing.

Breakpoint 5, add_tree_backref (extent_cache=0x7fffffffdf30, bytenr=3067669348352, parent=0, root=2, found_ref=0) at cmds-check.c:4624
4624		check_extent_type(rec);
(gdb) bt
#0  add_tree_backref (extent_cache=0x7fffffffdf30, bytenr=3067669348352, parent=0, root=2, found_ref=0) at cmds-check.c:4624
#1  0x000000000042edb8 in process_extent_item (root=0x919d20, extent_cache=0x7fffffffdf30, eb=0x1a0edb0, slot=96) at cmds-check.c:5157
#2  0x0000000000430aea in run_next_block (root=0x919d20, bits=0x91e220, bits_nr=1024, last=0x7fffffffdb78, pending=0x7fffffffdf10, seen=0x7fffffffdf20, reada=0x7fffffffdf00, 
    nodes=0x7fffffffdef0, extent_cache=0x7fffffffdf30, chunk_cache=0x7fffffffdf90, dev_cache=0x7fffffffdfa0, block_group_cache=0x7fffffffdf70, dev_extent_cache=0x7fffffffdf40, ri=0x6cef30)
    at cmds-check.c:5960
#3  0x00000000004356c4 in deal_root_from_list (list=0x7fffffffdc00, root=0x919d20, bits=0x91e220, bits_nr=1024, pending=0x7fffffffdf10, seen=0x7fffffffdf20, reada=0x7fffffffdf00, 
    nodes=0x7fffffffdef0, extent_cache=0x7fffffffdf30, chunk_cache=0x7fffffffdf90, dev_cache=0x7fffffffdfa0, block_group_cache=0x7fffffffdf70, dev_extent_cache=0x7fffffffdf40)
    at cmds-check.c:8014
#4  0x0000000000435d91 in check_chunks_and_extents (root=0x919d20) at cmds-check.c:8181
#5  0x0000000000438e2b in cmd_check (argc=1, argv=0x7fffffffe220) at cmds-check.c:9627
#6  0x0000000000409d49 in main (argc=2, argv=0x7fffffffe220) at btrfs.c:252

(btw: all lines are 4.3 including your patch)


breakpoint 5 would be reached many times:

Breakpoint 5, add_tree_backref (extent_cache=0x7fffffffdf30, bytenr=3067669348352, parent=0, root=2, found_ref=0) at cmds-check.c:4624
4624		check_extent_type(rec);
(gdb) continue 
Continuing.

Breakpoint 5, add_tree_backref (extent_cache=0x7fffffffdf30, bytenr=3067669348352, parent=0, root=7, found_ref=0) at cmds-check.c:4624
4624		check_extent_type(rec);
(gdb) continue 
Continuing.

Breakpoint 5, add_tree_backref (extent_cache=0x7fffffffdf30, bytenr=3067669348352, parent=0, root=7, found_ref=0) at cmds-check.c:4624
4624		check_extent_type(rec);
(gdb) continue 
Continuing.

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

  reply	other threads:[~2015-11-25  4:17 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 21:51 bad extent [5993525264384, 5993525280768), type mismatch with chunk Christoph Anton Mitterer
2015-11-12 22:23 ` Christoph Anton Mitterer
2015-11-13  2:13 ` Qu Wenruo
2015-11-13  2:26   ` Christoph Anton Mitterer
2015-11-13  2:52     ` Qu Wenruo
2015-11-13  3:03       ` Christoph Anton Mitterer
2015-11-13  3:23         ` Qu Wenruo
2015-11-13  3:31           ` Christoph Anton Mitterer
2015-11-13  3:44           ` Christoph Anton Mitterer
2015-11-13  3:57       ` Christoph Anton Mitterer
2015-11-13  7:05         ` Duncan
2015-11-13  9:55           ` Christoph Anton Mitterer
2015-11-13 11:37             ` Christoph Anton Mitterer
     [not found]       ` <564F48FE.4000400@laposte.net>
2015-11-20 19:24         ` Christoph Anton Mitterer
2015-11-21  0:47           ` Qu Wenruo
2015-11-21  1:08             ` Lukas Pirl
2015-11-22  2:04               ` Qu Wenruo
2015-11-22  6:56                 ` Christoph Anton Mitterer
2015-11-23  1:10                   ` Qu Wenruo
2015-11-23 18:12                     ` Christoph Anton Mitterer
2015-11-24  0:46                       ` Qu Wenruo
2015-11-24  1:53                         ` Christoph Anton Mitterer
2015-11-24  2:09                           ` Qu Wenruo
2015-11-24  2:48                             ` Christoph Anton Mitterer
2015-11-24  2:54                               ` Qu Wenruo
2015-11-24  3:02                                 ` Christoph Anton Mitterer
2015-11-24  5:35                                   ` Qu Wenruo
2015-11-24 18:25                                     ` Christoph Anton Mitterer
2015-11-25  0:02                                       ` Qu Wenruo
2015-11-25  0:59                                       ` Qu Wenruo
2015-11-25  3:35                                         ` Christoph Anton Mitterer
2015-11-25  4:16                                           ` Christoph Anton Mitterer [this message]
2015-11-24 17:39                         ` David Sterba
2015-11-22 10:17                 ` Laurent Bonnaud
2015-11-23  1:00                   ` Qu Wenruo
2015-11-24 13:15                     ` Laurent Bonnaud
2015-11-24 23:46                       ` Qu Wenruo
2015-11-25  9:05                         ` Laurent Bonnaud
2015-12-03 17:13                           ` Laurent Bonnaud
2015-12-04  0:47                             ` Qu Wenruo
2015-12-11 13:22                               ` Laurent Bonnaud
2015-12-11 14:21                               ` Laurent Bonnaud
2015-12-14  0:53                                 ` Qu Wenruo
2015-12-14 12:47                                 ` Laurent Bonnaud
2015-12-15  1:16                                   ` Qu Wenruo
2015-11-24 23:53                       ` Qu Wenruo
2015-11-14  1:22 ` Qu Wenruo
2015-11-14  2:29   ` Christoph Anton Mitterer
2015-11-15  1:29     ` Qu Wenruo
2015-11-15  3:24       ` Christoph Anton Mitterer
2016-02-16  0:14 ` Ángel González
2016-02-16  1:38   ` Qu Wenruo
2016-02-16 22:21     ` Ángel González
2016-02-17  7:26       ` Qu Wenruo
2016-02-17 23:56         ` Ángel González

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1448425015.21291.142.camel@scientia.net \
    --to=calestyo@scientia.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).