linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk
Date: Sun, 15 Nov 2015 04:24:00 +0100	[thread overview]
Message-ID: <1447557840.20381.29.camel@scientia.net> (raw)
In-Reply-To: <5647DFED.5020507@gmx.com>

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

On Sun, 2015-11-15 at 09:29 +0800, Qu Wenruo wrote:
> > > If type is wrong, all the extents inside the chunk should be
> > > reported
> > > as
> > > mismatch type with chunk.
> > Isn't that the case? At least there are so many reported extents...
> 
> If you posted all the output
Sure, I posted everything that the dump gave :)

> , that's just a little more than nothing.
> Just tens of error reported, compared to millions of extents.
> And in your case, if a chunk is really bad, it will report about 65K
> errors.
I see..


> I think it's a btrfsck issue, at least from the dump info, your
> extent 
> tree is OK.
> And if there is no other error reported from btrfsck, your filesystem
> should be OK.
Nope.. there were no further errors.



> > In any case, I'll keep the fs in question for a while, so that I
> > can do
> > verifications in case you have patches.
> 
> Nice.
Just tell me if you have something.



btw: I saw these:
Nov 15 02:01:42 heisenberg kernel: INFO: task btrfs-transacti:28379 blocked for more than 120 seconds.
Nov 15 02:01:42 heisenberg kernel:       Not tainted 4.2.0-1-amd64 #1
Nov 15 02:01:42 heisenberg kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 15 02:01:42 heisenberg kernel: btrfs-transacti D ffffffff8109a1b0     0 28379      2 0x00000000
Nov 15 02:01:42 heisenberg kernel:  ffff88016e3e6500 0000000000000046 000000000000007a ffff88040be88f00
Nov 15 02:01:42 heisenberg kernel:  0000000000002659 ffff880138070000 ffff88041e355840 7fffffffffffffff
Nov 15 02:01:42 heisenberg kernel:  ffffffff815508e0 ffff88013806fbb8 0007ffffffffffff ffffffff815500ff
Nov 15 02:01:42 heisenberg kernel: Call Trace:
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff815508e0>] ? bit_wait_timeout+0x70/0x70
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff815500ff>] ? schedule+0x2f/0x70
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff81552bc7>] ? schedule_timeout+0x1f7/0x290
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa02be6f2>] ? extent_write_cache_pages.isra.28.constprop.43+0x222/0x330 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff8101c325>] ? read_tsc+0x5/0x10
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff815508e0>] ? bit_wait_timeout+0x70/0x70
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff8154f7ad>] ? io_schedule_timeout+0x9d/0x110
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff81550915>] ? bit_wait_io+0x35/0x60
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff815504ca>] ? __wait_on_bit+0x5a/0x90
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff81152496>] ? find_get_pages_tag+0x116/0x150
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff811513a6>] ? wait_on_page_bit+0xb6/0xc0
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff810a9b20>] ? autoremove_wake_function+0x40/0x40
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff81151477>] ? filemap_fdatawait_range+0xc7/0x140
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa02b9a43>] ? btrfs_wait_ordered_range+0x73/0x110 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa02e3c1d>] ? btrfs_wait_cache_io+0x5d/0x1e0 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa028e7bc>] ? btrfs_start_dirty_block_groups+0x17c/0x3f0 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa029ee84>] ? btrfs_commit_transaction+0x1b4/0xa90 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa029f7f0>] ? start_transaction+0x90/0x580 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa029a654>] ? transaction_kthread+0x224/0x240 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffffa029a430>] ? btrfs_cleanup_transaction+0x510/0x510 [btrfs]
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff8108aa41>] ? kthread+0xc1/0xe0
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff8108a980>] ? kthread_create_on_node+0x170/0x170
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff81553e5f>] ? ret_from_fork+0x3f/0x70
Nov 15 02:01:42 heisenberg kernel:  [<ffffffff8108a980>] ? kthread_create_on_node+0x170/0x170
Nov 15 02:03:42 heisenberg kernel: INFO: task btrfs-transacti:28379 blocked for more than 120 seconds.
Nov 15 02:03:42 heisenberg kernel:       Not tainted 4.2.0-1-amd64 #1
Nov 15 02:03:42 heisenberg kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 15 02:03:42 heisenberg kernel: btrfs-transacti D ffffffff8109a1b0     0 28379      2 0x00000000
Nov 15 02:03:42 heisenberg kernel:  ffff88016e3e6500 0000000000000046 000000000000007a ffff88040be88f00
Nov 15 02:03:42 heisenberg kernel:  0000000000002659 ffff880138070000 ffff88041e355840 7fffffffffffffff
Nov 15 02:03:42 heisenberg kernel:  ffffffff815508e0 ffff88013806fbb8 0007ffffffffffff ffffffff815500ff
Nov 15 02:03:42 heisenberg kernel: Call Trace:
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff815508e0>] ? bit_wait_timeout+0x70/0x70
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff815500ff>] ? schedule+0x2f/0x70
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff81552bc7>] ? schedule_timeout+0x1f7/0x290
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa02be6f2>] ? extent_write_cache_pages.isra.28.constprop.43+0x222/0x330 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff8101c325>] ? read_tsc+0x5/0x10
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff815508e0>] ? bit_wait_timeout+0x70/0x70
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff8154f7ad>] ? io_schedule_timeout+0x9d/0x110
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff81550915>] ? bit_wait_io+0x35/0x60
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff815504ca>] ? __wait_on_bit+0x5a/0x90
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff81152496>] ? find_get_pages_tag+0x116/0x150
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff811513a6>] ? wait_on_page_bit+0xb6/0xc0
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff810a9b20>] ? autoremove_wake_function+0x40/0x40
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff81151477>] ? filemap_fdatawait_range+0xc7/0x140
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa02b9a43>] ? btrfs_wait_ordered_range+0x73/0x110 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa02e3c1d>] ? btrfs_wait_cache_io+0x5d/0x1e0 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa028e7bc>] ? btrfs_start_dirty_block_groups+0x17c/0x3f0 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa029ee84>] ? btrfs_commit_transaction+0x1b4/0xa90 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa029f7f0>] ? start_transaction+0x90/0x580 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa029a654>] ? transaction_kthread+0x224/0x240 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffffa029a430>] ? btrfs_cleanup_transaction+0x510/0x510 [btrfs]
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff8108aa41>] ? kthread+0xc1/0xe0
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff8108a980>] ? kthread_create_on_node+0x170/0x170
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff81553e5f>] ? ret_from_fork+0x3f/0x70
Nov 15 02:03:42 heisenberg kernel:  [<ffffffff8108a980>] ? kthread_create_on_node+0x170/0x170
Nov 15 04:18:37 heisenberg kernel: virbr1: port 2(vnet0) entered disabled state
Nov 15 04:18:37 heisenberg kernel: device vnet0 left promiscuous mode
Nov 15 04:18:37 heisenberg kernel: virbr1: port 2(vnet0) entered disabled state

Is that anything to worry about? And any way to find out to which
filesystem that process corresponds?
At least I've never seen  btrfs-transacti to hang... and since nothing
than the cp -a from on to the other disk is doing anything on the two
HDDs, I was a bit surprised to see that happen


Cheers,
Chris.

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

  reply	other threads:[~2015-11-15  3:24 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
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 [this message]
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=1447557840.20381.29.camel@scientia.net \
    --to=calestyo@scientia.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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).