Red Hat Bugzilla – Bug 496901
kernel BUG at fs/btrfs/extent-tree.c:2880
Last modified: 2017-07-24 17:24:45 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 (220.127.116.11-100.fc11.i686.PAE #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
[<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):
Steps to Reproduce:
do you have the full log message? I hate how it says "cut here" but really i need the info above that line too.
I'm attaching a full dmesg from that machine.
Created attachment 340784 [details]
dmesg output from failing system
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.
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.
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.
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!
Created attachment 340837 [details]
lzma-compressed output from btrfs-debug-tree (root)
Created attachment 340841 [details]
lzma-compressed output from btrfs-debug-tree (/local/spool)
Okay to close this?
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:
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:
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.