Thomas Harning
2008-Dec-16 19:57 UTC
kernel BUG: kernel bug caught at 55% mark of portage cache update
A kernel ''BUG'' was caught while I had compression enabled and
was
performing a ''portage'' update on my gentoo installation (which
had
btrfs mounted for portage for some basic perf testing). It has
finished the rsync and was at the 55% mark of the portage cache
update... if that helps at all.
Inlined is the kernel bug output... + some extra debug info that had
been spit out beforehand that i thought might be useful...
didn''t appear to be at that 85% freespace mark...
should I attach a btrfs-image dump?
/dev/mapper/vg-btrfsTest
1.0G 309M 716M 31% /mnt/btrfsTest
device fsid 6c44efb8af8339de-fdcb30fce5264c82 devid 1 transid 22 /dev/
mapper/vg-btrfsTest
space info full 36
we were searching for 4096 bytes, num_bytes 4096, loop 2,
allowed_alloc 1
allocation failed flags 36, wanted 4096
space_info has 65536 free, is full
block group 29360128 has 53673984 bytes, 50790400 used 2818048 pinned
0 reserved
0 blocks of free space at or bigger than bytes is
block group 190382080 has 53673984 bytes, 50040832 used 3633152 pinned
0 reserved
0 blocks of free space at or bigger than bytes is
block group 244056064 has 53673984 bytes, 50913280 used 2760704 pinned
0 reserved
0 blocks of free space at or bigger than bytes is
block group 297730048 has 53673984 bytes, 50917376 used 2756608 pinned
0 reserved
0 blocks of free space at or bigger than bytes is
block group 351404032 has 53673984 bytes, 36831232 used 16842752
pinned 0 reserved
0 blocks of free space at or bigger than bytes is
block group 405078016 has 53673984 bytes, 19693568 used 33980416
pinned 0 reserved
0 blocks of free space at or bigger than bytes is
block group 566099968 has 53673984 bytes, 49348608 used 4325376 pinned
0 reserved
0 blocks of free space at or bigger than bytes is
------------[ cut here ]------------
kernel BUG at /home/harningt/gitrepo/kernel/btrfs-unstable-standalone/
extent-tree.c:3096!
invalid opcode: 0000 [1]
CPU 0
Modules linked in: btrfs crc32c libcrc32c zlib_deflate nvidia(P) fuse
snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device snd_atiixp snd_ac97_codec ac97_bus snd_pcm
snd_timer snd snd_page_alloc
Pid: 4539, comm: emerge Tainted: P 2.6.27-00080-g13d5f30 #1
RIP: 0010:[<ffffffffa0824718>] [<ffffffffa0824718>]
__btrfs_reserve_extent+0x278/0x2b0 [btrfs]
RSP: 0018:ffff880029a25908 EFLAGS: 00010296
RAX: ffff880048118560 RBX: ffff880044468400 RCX: 000000000000ffff
RDX: 00000000ffffff01 RSI: 0000000000000000 RDI: ffff880048118558
RBP: ffff880048118548 R08: 0000000000008b1a R09: 00000000ffffffff
R10: 0000000000000000 R11: 000000000000000a R12: 0000000000001000
R13: ffff880048118558 R14: ffff880048118548 R15: 0000000000001000
FS: 00007f671a6896f0(0000) GS:ffffffff8087fe80(0000) knlGS:
00000000f7c7d6c0
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001bd1024 CR3: 000000002b39c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process emerge (pid: 4539, threadinfo ffff880029a24000, task
ffff880049991740)
Stack: 0000000000000000 ffff880029a25a08 0000000000000000
0000000000000000
0000000400000024 0000000000000000 0000000000000000 0000000000001000
ffff880031723800 ffff880029a25a08 0000000000000005 ffff8800437a9070
Call Trace:
[<ffffffffa082561c>] ? btrfs_alloc_extent+0x4c/0xc0 [btrfs]
[<ffffffffa08256f4>] ? btrfs_alloc_free_block+0x64/0xa0 [btrfs]
[<ffffffffa0815be6>] ? __btrfs_cow_block+0x1f6/0x8a0 [btrfs]
[<ffffffffa08168e4>] ? btrfs_cow_block+0x134/0x210 [btrfs]
[<ffffffffa081d1c4>] ? btrfs_search_slot+0x1f4/0x910 [btrfs]
[<ffffffff80261895>] ? __pagevec_lru_add+0x95/0xa0
[<ffffffffa084e8be>] ? extent_readpages+0x15e/0x180 [btrfs]
[<ffffffff8025ed46>] ? __alloc_pages_internal+0xb6/0x470
[<ffffffffa082d182>] ? btrfs_lookup_inode+0x32/0xb0 [btrfs]
[<ffffffffa0834d2d>] ? btrfs_update_inode+0x3d/0xc0 [btrfs]
[<ffffffffa0834f93>] ? btrfs_dirty_inode+0x43/0x60 [btrfs]
[<ffffffff802a0864>] ? __mark_inode_dirty+0x34/0x190
[<ffffffff8029642e>] ? touch_atime+0xfe/0x170
[<ffffffff8025be21>] ? generic_file_aio_read+0x581/0x5e0
[<ffffffff80281dc9>] ? do_sync_read+0xd9/0x120
[<ffffffff80242360>] ? autoremove_wake_function+0x0/0x30
[<ffffffff8020fee6>] ? arch_get_unmapped_area_topdown+0x206/0x2b0
[<ffffffff80281f65>] ? vfs_read+0xc5/0x180
[<ffffffff80282523>] ? sys_read+0x53/0x90
[<ffffffff8020b5eb>] ? system_call_fastpath+0x16/0x1b
Code: ff 31 c0 e8 cb bf a0 df 4c 89 e6 48 89 df e8 40 93 03 00 48 8b
6d 00 48 8b 45 00 4c 39 f5 0f 18 08 75 b3 4c 89 ef e8 a8 0d a2 df <0f>
0b eb fe be 03 0c 00 00 48 c7 c7 30 00 86 a0 e8 63 af a0 df
RIP [<ffffffffa0824718>] __btrfs_reserve_extent+0x278/0x2b0 [btrfs]
RSP <ffff880029a25908>
---[ end trace cdb8403d4defddf6 ]---
--
Thomas Harning
TrustBearer Labs
TB OpenID: https://openid.trustbearer.com/harningt
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2008-Dec-19 16:16 UTC
Re: kernel BUG: kernel bug caught at 55% mark of portage cache update
On Tue, 2008-12-16 at 14:57 -0500, Thomas Harning wrote:> A kernel ''BUG'' was caught while I had compression enabled and was > performing a ''portage'' update on my gentoo installation (which had > btrfs mounted for portage for some basic perf testing). It has > finished the rsync and was at the 55% mark of the portage cache > update... if that helps at all. > > Inlined is the kernel bug output... + some extra debug info that had > been spit out beforehand that i thought might be useful... > > didn''t appear to be at that 85% freespace mark... > > should I attach a btrfs-image dump? > > /dev/mapper/vg-btrfsTest > 1.0G 309M 716M 31% /mnt/btrfsTest >Looking at the logs, your disk really was full. Btrfs breaks the disk up into metadata and data chunks. The allocator is much more efficient when the chunks are fairly large (the default is 1GB), and for smaller devices it tries to make them smaller. There is some tuning that needs to happen on the smaller devices to better balance space between data and metadata. In your case, the metadata block groups were all full even though the data block groups still had some empty space. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Julian Andres Klode
2008-Dec-19 16:24 UTC
Re: kernel BUG: kernel bug caught at 55% mark of portage cache update
2008/12/19 Chris Mason <chris.mason@oracle.com>:> On Tue, 2008-12-16 at 14:57 -0500, Thomas Harning wrote: >> A kernel ''BUG'' was caught while I had compression enabled and was >> performing a ''portage'' update on my gentoo installation (which had >> btrfs mounted for portage for some basic perf testing). It has >> finished the rsync and was at the 55% mark of the portage cache >> update... if that helps at all. >> >> Inlined is the kernel bug output... + some extra debug info that had >> been spit out beforehand that i thought might be useful... >> >> didn''t appear to be at that 85% freespace mark... >> >> should I attach a btrfs-image dump? >> >> /dev/mapper/vg-btrfsTest >> 1.0G 309M 716M 31% /mnt/btrfsTest >> > > Looking at the logs, your disk really was full. Btrfs breaks the disk > up into metadata and data chunks. The allocator is much more efficient > when the chunks are fairly large (the default is 1GB), and for smaller > devices it tries to make them smaller. > > There is some tuning that needs to happen on the smaller devices to > better balance space between data and metadata. In your case, the > metadata block groups were all full even though the data block groups > still had some empty space.I can reproduce this bug at the same location, simply by running bonnie++ on a 4GB btrfs partition. I already wrote this one week ago to this list (4 times), but it did not show up on the list.> > > -chris > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- Julian Andres Klode - Free Software Developer Debian Developer - Contributing Member of SPI Ubuntu Member - Fellow of FSFE Website: http://jak-linux.org/ XMPP: juliank@jabber.org Debian: http://www.debian.org/ SPI: http://www.spi-inc.org/ Ubuntu: http://www.ubuntu.com/ FSFE: http://www.fsfe.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2008-Dec-19 16:32 UTC
Re: kernel BUG: kernel bug caught at 55% mark of portage cache update
On Fri, 2008-12-19 at 17:24 +0100, Julian Andres Klode wrote:> 2008/12/19 Chris Mason <chris.mason@oracle.com>: > > On Tue, 2008-12-16 at 14:57 -0500, Thomas Harning wrote: > >> A kernel ''BUG'' was caught while I had compression enabled and was > >> performing a ''portage'' update on my gentoo installation (which had > >> btrfs mounted for portage for some basic perf testing). It has > >> finished the rsync and was at the 55% mark of the portage cache > >> update... if that helps at all. > >> > >> Inlined is the kernel bug output... + some extra debug info that had > >> been spit out beforehand that i thought might be useful... > >> > >> didn''t appear to be at that 85% freespace mark... > >> > >> should I attach a btrfs-image dump? > >> > >> /dev/mapper/vg-btrfsTest > >> 1.0G 309M 716M 31% /mnt/btrfsTest > >> > > > > Looking at the logs, your disk really was full. Btrfs breaks the disk > > up into metadata and data chunks. The allocator is much more efficient > > when the chunks are fairly large (the default is 1GB), and for smaller > > devices it tries to make them smaller. > > > > There is some tuning that needs to happen on the smaller devices to > > better balance space between data and metadata. In your case, the > > metadata block groups were all full even though the data block groups > > still had some empty space. > > I can reproduce this bug at the same location, simply by running > bonnie++ on a 4GB btrfs partition. I > already wrote this one week ago to this list (4 times), but it did not > show up on the list.Yes, btrfs does not deal with enospc very well. This is next on my list of major improvements to start on. bonnie writes a fairly large file, as I wrote above you''re running into the chunk allocation schemes that split data and metadata. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html