Bug 496901 - kernel BUG at fs/btrfs/extent-tree.c:2880
kernel BUG at fs/btrfs/extent-tree.c:2880
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Josef Bacik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-21 11:24 EDT by Carl Roth
Modified: 2017-07-24 17:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-28 08:08:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
roth: needinfo-

Attachments (Terms of Use)
dmesg output from failing system (57.30 KB, text/plain)
2009-04-22 14:17 EDT, Carl Roth
no flags Details
lzma-compressed output from btrfs-debug-tree (root) (8.58 MB, application/x-lzma)
2009-04-22 17:56 EDT, Carl Roth
no flags Details
lzma-compressed output from btrfs-debug-tree (/local/spool) (3.24 MB, application/x-lzma)
2009-04-22 18:05 EDT, Carl Roth
no flags Details

  None (edit)
Description Carl Roth 2009-04-21 11:24:56 EDT
Description of problem:

I set up a test machine with F11 beta/rawhide, using the btrfs for its filesystems.  The latest YUM upgrade I tried ran 'restorecon' as part of its transaction, and it failed with

------------[ cut here ]------------
kernel BUG at fs/btrfs/extent-tree.c:2880!
invalid opcode: 0000 [#3] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/rfkill/rfkill1/state
Modules linked in: rfcomm bridge stp llc bnep sco l2cap sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq vfat fat dm_multipath uinput btusb arc4 bluetooth ecb asix snd_hda_codec_analog usbnet iwl3945 snd_hda_intel iTCO_wdt thinkpad_acpi snd_hda_codec nsc_ircc mii iTCO_vendor_support i2c_i801 pcspkr hwmon video yenta_socket rsrc_nonstatic snd_hwdep snd_pcm joydev snd_timer snd mac80211 output soundcore lib80211 irda snd_page_alloc cfg80211 crc_ccitt btrfs zlib_deflate libcrc32c radeon drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]

Pid: 21201, comm: restorecon Tainted: G      D    ( #1) 2613EKU
EIP: 0060:[<f8660308>] EFLAGS: 00010257 CPU: 0
EIP is at __btrfs_reserve_extent+0x33f/0x34d [btrfs]
EAX: f5194adc EBX: f5194a44 ECX: 00000000 EDX: 00000001
ESI: f5194adc EDI: f637faac EBP: c9817c94 ESP: c9817c3c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process restorecon (pid: 21201, ti=c9816000 task=e98158d0 task.ti=c9816000)
 00000010 00000004 00000000 c9817d77 ffffffff ffffffff 00000000 00000000
 00000000 00000000 c200e7ac 00000000 00001000 00000000 00000000 f4cb6ba0
 f5194ad0 00001000 00000000 c9817d77 f4cb6ba0 c9817d08 c9817d00 f866038d
Call Trace:
 [<f866038d>] ? btrfs_alloc_extent+0x77/0xe6 [btrfs]
 [<f8660465>] ? btrfs_alloc_free_block+0x69/0x97 [btrfs]
 [<f865864a>] ? __btrfs_cow_block+0x12a/0x4cd [btrfs]
 [<c042759c>] ? kmap_atomic+0x19/0x1b
 [<c042757d>] ? kmap_atomic_prot+0x200/0x206
 [<f865909f>] ? btrfs_cow_block+0x134/0x13f [btrfs]
 [<f865a970>] ? btrfs_search_slot+0x122/0x4e8 [btrfs]
 [<f8667573>] ? btrfs_lookup_inode+0x2f/0x8b [btrfs]
 [<f8658150>] ? btrfs_alloc_path+0x17/0x24 [btrfs]
 [<f867060a>] ? btrfs_update_inode+0x48/0xba [btrfs]
 [<f8672fdb>] ? btrfs_dirty_inode+0x49/0x59 [btrfs]
 [<c04c0bfd>] ? __mark_inode_dirty+0x2e/0x12d
 [<c04b8de2>] ? touch_atime+0xce/0xd5
 [<c04b525d>] ? vfs_readdir+0x7b/0x94
 [<c04b4f38>] ? filldir64+0x0/0xf4
 [<c04b52e8>] ? sys_getdents64+0x72/0xb2
 [<c04094df>] ? sysenter_do_call+0x12/0x34
Code: dc c7 90 8b 9b 8c 00 00 00 81 eb 8c 00 00 00 8b 83 8c 00 00 00 0f 18 00 90 8d 83 8c 00 00 00 39 45 e8 75 96 89 f0 e8 cf b5 de c7 <0f> 0b eb fe 8d 65 f4 31 c0 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 
EIP: [<f8660308>] __btrfs_reserve_extent+0x33f/0x34d [btrfs] SS:ESP 0068:c9817c3c
---[ end trace 8262701c0652a0cc ]---

The 'restorecon' process became unresponsive (I killed it eventually).  The rest of the YUM transaction completed, but after that point I had a bunch of zombie restorecon processes laying around.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Josef Bacik 2009-04-22 14:02:05 EDT
do you have the full log message?  I hate how it says "cut here" but really i need the info above that line too.
Comment 2 Carl Roth 2009-04-22 14:16:04 EDT
I'm attaching a full dmesg from that machine.
Comment 3 Carl Roth 2009-04-22 14:17:01 EDT
Created attachment 340784 [details]
dmesg output from failing system
Comment 4 Josef Bacik 2009-04-22 14:28:35 EDT
sorry, you've run out of space.  this is one of the things about btrfs right now, it does not handle running out of space well.  If you can add more space to the volume then I would do that.  If not re-install, and then build a kernel with this patch


this will make sure you don't run out of metadata space, but it will mean that you lose some of your disk to metadata, 12.5% of your disk to be exact.  You can tweak this with the metadata_ratio mount option, so if thats a bit high for you then you can lower it a bit by setting metadata_ratio to a number higher than 8.
Comment 5 Carl Roth 2009-04-22 14:40:57 EDT
What do you mean by "out of space"?  Are we talking about disk space?  If so there should be plenty:

Filesystem            Size  Used Avail Use% Mounted on
                       16G  3.8G   13G  24% /
/dev/sda2             5.0G  4.2G  858M  84% /local/windows
                      2.0G  924M  1.1G  46% /local/spool
/dev/sda1             101M   42M   54M  44% /boot
                      2.0G  104M  1.9G   6% /local/data
tmpfs                1007M     0 1007M   0% /dev/shm

I also ran btrfsck on these filesystems and there were no issues reported.
Comment 6 Josef Bacik 2009-04-22 14:56:37 EDT
the way btrfs splits up space is by chunks.  so you have metadata chunks and data chunks, and it will allocate each chunk as it sees fit.  So in your case it seems all of the chunks that can be allocated have been allocated, and you've run out of metadata space.  Since we can't allocate anymore metadata chunks, and there is no metadata space left, you can't do anything.  You can run debug-tree against your disk and redirect the output to a file and attach it to this bz so I can verify thats what happened if you like, but this is a common problem with btrfs, which is why you have to jump through hoops to install onto it.
Comment 7 Carl Roth 2009-04-22 17:52:22 EDT
ha ha you should have warned me to not run btrfs-debug-tree on a rw mounted filesystem...

In any case here are traces for two of the filesystems in question; I hope you know how to read them because the outputs are huge!
Comment 8 Carl Roth 2009-04-22 17:56:20 EDT
Created attachment 340837 [details]
lzma-compressed output from btrfs-debug-tree (root)
Comment 9 Carl Roth 2009-04-22 18:05:58 EDT
Created attachment 340841 [details]
lzma-compressed output from btrfs-debug-tree (/local/spool)
Comment 10 Chuck Ebbert 2009-06-09 01:25:36 EDT
Okay to close this?
Comment 11 Bug Zapper 2009-06-09 10:19:26 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 12 Bug Zapper 2010-04-27 09:51:21 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 13 Bug Zapper 2010-06-28 08:08:59 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.