From: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: liubo <liubo2009@cn.fujitsu.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
Date: Wed, 08 Jun 2011 14:12:47 +0900 [thread overview]
Message-ID: <4DEF04CF.8010502@jp.fujitsu.com> (raw)
In-Reply-To: <1307461229-sup-9822@shiny>
(2011/06/08 0:46), Chris Mason wrote:
> Excerpts from liubo's message of 2011-06-07 04:36:56 -0400:
>> On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
>>> (2011/06/07 15:17), Tsutomu Itoh wrote:
>>>> (2011/06/07 14:59), Tsutomu Itoh wrote:
>>>>> Hi liubo,
>>>>>
>>>>> (2011/06/07 14:31), liubo wrote:
>>>>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>>>>>> kernel.
>>>>>>>
>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>>>>>> is as follows:
>>>>>>>
>>>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>>>>>
>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>> I think so.
>
> It should be specific to the inode caching code. The balancing code is
> finding the inode map cache extents, but it doesn't know how to relocate
> them.
However, the panic has occurred even if inode_cahce is turned off.
Is this another problem?
---
Tsutomu
====================================================================
device fsid a46d03b5cb35c93-4713fead8acc709e devid 1 transid 7 /dev/sdc3
btrfs: enabling disk space caching
btrfs: use lzo compression
device fsid 914b303425ef9825-e448135c0d20babe devid 1 transid 7 /dev/sdd4
btrfs: disk space caching is enabled
btrfs: relocating block group 1103101952 flags 9
btrfs: found 540 extents
btrfs: found 540 extents
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent-tree.c:1424!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/kernel/mm/ksm/run
CPU 0
Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
Pid: 26884, comm: btrfs Not tainted 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
RIP: 0010:[<ffffffffa0325422>] [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
RSP: 0018:ffff8801475db748 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff880141d1a6d0 RCX: ffff8801475da000
RDX: 0000000000000008 RSI: ffff880000000000 RDI: 0000000000000000
RBP: ffff8801475db7e8 R08: 0000000000000001 R09: 6db6db6db6db6db7
R10: 0000000000000001 R11: 0000000000000014 R12: 00000000000000b8
R13: ffff880142bc8a08 R14: 0000000000000001 R15: 000000000000000d
FS: 00007fbbaa8b0740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000033cfeda340 CR3: 0000000145c04000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btrfs (pid: 26884, threadinfo ffff8801475da000, task ffff880160806ab0)
Stack:
ffff8801475db778 ffffffffa0331ca6 ffff88018c1087c8 ffff8801475db830
0000000000000821 0000000181f43000 ffff8801475db7e8 ffff88012cc27800
000000000000082e 00000794475db9a9 0000000181f43000 00000000004000a8
Call Trace:
[<ffffffffa0331ca6>] ? btrfs_mark_buffer_dirty+0xb6/0x130 [btrfs]
[<ffffffffa03255a9>] insert_inline_extent_backref+0x69/0x100 [btrfs]
[<ffffffff81140376>] ? kmem_cache_alloc+0x186/0x190
[<ffffffffa03256e3>] __btrfs_inc_extent_ref+0xa3/0x1e0 [btrfs]
[<ffffffffa0326d19>] ? update_block_group+0xd9/0x2a0 [btrfs]
[<ffffffffa0327e94>] run_clustered_refs+0x664/0x7f0 [btrfs]
[<ffffffffa03280e8>] btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
[<ffffffffa033638d>] btrfs_commit_transaction+0x7d/0x790 [btrfs]
[<ffffffff81081de0>] ? wake_up_bit+0x40/0x40
[<ffffffffa037922d>] prepare_to_merge+0x1fd/0x230 [btrfs]
[<ffffffffa037f306>] relocate_block_group+0x476/0x660 [btrfs]
[<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
[<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
[<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
[<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
[<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
[<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
[<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
[<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
[<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
[<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
[<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
[<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
Code: 48 8b 75 20 48 89 c3 48 8b 7d 18 e8 c9 bd ff ff 48 39 d8 77 26 b8 1d 00 00 00 e9 15 ff ff ff a8 01 0f 85 8c fe ff ff 0f 0b eb fe <0f> 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 4c 89 fb 44 8b
RIP [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
RSP <ffff8801475db748>
>
> I think we need to switch the inode map cache over to regular extents
> that are not preallocated. It will fix the overflow problem and it will
> fix the balancing.
>
> There are a lot of special cases for the free extent cache that don't
> apply to the inode map cache, and I think sharing the extent
> preallocation is hurting us.
>
> -chris
>
>
next prev parent reply other threads:[~2011-06-08 5:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 8:33 kernel BUG at fs/btrfs/extent-tree.c:6164! Tsutomu Itoh
2011-06-07 5:31 ` liubo
2011-06-07 5:59 ` Tsutomu Itoh
2011-06-07 6:17 ` Tsutomu Itoh
2011-06-07 8:24 ` Tsutomu Itoh
2011-06-07 8:36 ` liubo
2011-06-07 15:46 ` Chris Mason
2011-06-08 5:12 ` Tsutomu Itoh [this message]
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
2011-06-13 7:49 ` Yan, Zheng
2011-06-13 8:26 ` Li Zefan
2011-06-13 13:12 ` Chris Mason
2011-06-13 15:18 ` Chris Mason
2011-06-13 14:58 ` Yan, Zheng
2011-06-13 15:09 ` Chris Mason
2011-06-13 19:55 ` Chris Mason
2011-06-14 3:24 ` Yan, Zheng
2011-06-14 5:44 ` Li Zefan
2011-06-14 6:53 ` Yan, Zheng
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=4DEF04CF.8010502@jp.fujitsu.com \
--to=t-itoh@jp.fujitsu.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=liubo2009@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.