Re: Regression in btrfs-next: BUG at fs/btrfs/super.c:984!
On Sat, Oct 01, 2011 at 11:43:10PM +0200, Maciej Marcin Piechotka wrote:
PS. It might happened that it was caused by parition mounted read-only
on read-only block device.
^^^
This is the key information!
super.c: btrfs_calc_avail_data_space()
983 nr_devices = fs_info-fs_devices-rw_devices;
984 BUG_ON(!nr_devices);
If there are no writable devices, this BUGON fires, although this case
in connection with RO mount is handled elsewhere properly.
This is called through sysfs and just tries to obtain available free
space information to print it. I think the BUG_ON is not necessary here
and the function can take a short track returning 0 as available free
space:
if (!nr_devices) {
*free_bytes = 0;
return 0;
}
I could be possible to actually read the free space even from a RO
device (be it RO mount or not), but I don't see much benefit which would
justify the work.
Can you please test the fix and let us know if the statfs number look
reasonable?
david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression in btrfs-next: BUG at fs/btrfs/super.c:984!
On Sun, 2011-10-02 at 19:39 +0200, David Sterba wrote:
On Sat, Oct 01, 2011 at 11:43:10PM +0200, Maciej Marcin Piechotka wrote:
PS. It might happened that it was caused by parition mounted read-only
on read-only block device.
^^^
This is the key information!
super.c: btrfs_calc_avail_data_space()
983 nr_devices = fs_info-fs_devices-rw_devices;
984 BUG_ON(!nr_devices);
If there are no writable devices, this BUGON fires, although this case
in connection with RO mount is handled elsewhere properly.
This is called through sysfs and just tries to obtain available free
space information to print it. I think the BUG_ON is not necessary here
and the function can take a short track returning 0 as available free
space:
if (!nr_devices) {
*free_bytes = 0;
return 0;
}
I could be possible to actually read the free space even from a RO
device (be it RO mount or not), but I don't see much benefit which would
justify the work.
Can you please test the fix and let us know if the statfs number look
reasonable?
david
Well - it shows size 50G, used 29G and avail 0G in df -h.
Regards
signature.asc
Description: This is a digitally signed message part
Regression in btrfs-next: BUG at fs/btrfs/super.c:984!
After merging btrfs-next patches (chris' btrfs-3.0 branch) I get following error: [ 9799.199495] [ cut here ] [ 9799.199511] kernel BUG at fs/btrfs/super.c:984! [ 9799.199524] invalid opcode: [#1] PREEMPT SMP [ 9799.199539] CPU 1 [ 9799.199542] Modules linked in: cpufreq_stats btrfs zlib_deflate libcrc32c microcode reiserfs arc4 snd_hda_codec_conexant uvcvideo cdc_ether usbnet videodev v4l2_compat_ioctl32 cdc_acm cdc_wdm btusb snd_hda_intel iwlagn bluetooth mac80211 snd_hda_codec snd_hwdep snd_pcm cfg80211 snd_timer snd soundcore snd_page_alloc e1000e thinkpad_acpi hwmon rfkill nvram zcache(PC) zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse fscache kvm_intel kvm loop configs ipv6 autofs4 uhci_hcd firewire_ohci sdhci_pci firewire_core sr_mod ehci_hcd sdhci mmc_core crc_itu_t cdrom sd_mod usbcore [ 9799.199657] [ 9799.199669] Pid: 2263, comm: df Tainted: P C 3.0.4-ck1+ #1 LENOVO 2242CTO/2242CTO [ 9799.199686] RIP: 0010:[a032b682] [a032b682] btrfs_statfs+0x108/0x3a9 [btrfs] [ 9799.199716] RSP: 0018:8800414f9de8 EFLAGS: 00010246 [ 9799.199728] RAX: 880129bf8000 RBX: 8800414f9f00 RCX: 880129bfa30c [ 9799.199742] RDX: 880129c8e240 RSI: 9123683e RDI: [ 9799.199756] RBP: 880129bf8000 R08: 810d1ad0 R09: 0203 [ 9799.199769] R10: 88012254eab0 R11: 0203 R12: 88011ba433c0 [ 9799.199783] R13: R14: 00885fa0 R15: 880129bfa368 [ 9799.199797] FS: 7f15983f7700() GS:88013bc8() knlGS: [ 9799.199811] CS: 0010 DS: ES: CR0: 80050033 [ 9799.199824] CR2: 015fa008 CR3: 8e5d5000 CR4: 000406e0 [ 9799.199838] DR0: DR1: DR2: [ 9799.199851] DR3: DR6: 0ff0 DR7: 0400 [ 9799.199865] Process df (pid: 2263, threadinfo 8800414f8000, task 8800b8426780) [ 9799.199878] Stack: [ 9799.199889] 8800414f9ed8 810d1ad0 88013162e4f8 [ 9799.199906] 880129f3c900 88012cdf3800 880129bf8000 000c430fe005 [ 9799.199923] 880132b0f540 88011badc958 880129bfa3c0 [ 9799.199940] Call Trace: [ 9799.199955] [810d1ad0] ? user_path_at+0x55/0x7b [ 9799.199971] [810e5f2c] ? statfs_by_dentry+0x46/0x5d [ 9799.199985] [810e5f56] ? vfs_statfs+0x13/0x8b [ 9799.19] [810d1ad0] ? user_path_at+0x55/0x7b [ 9799.26] [810e5ffe] ? user_statfs+0x30/0x48 [ 9799.26] [810e6068] ? sys_statfs+0x12/0x2b [ 9799.26] [8136607b] ? system_call_fastpath+0x16/0x1b [ 9799.26] Code: 18 48 89 33 4c 89 6b 20 48 89 43 08 48 8b 44 24 28 48 8b 80 20 01 00 00 48 8b 90 b8 23 00 00 48 89 44 24 30 8b 7a 30 85 ff 75 02 0f 0b 48 63 ff be 50 00 00 00 48 89 54 24 20 48 c1 e7 05 e8 56 [ 9799.26] RIP [a032b682] btrfs_statfs+0x108/0x3a9 [btrfs] [ 9799.26] RSP 8800414f9de8 [ 9799.221655] ---[ end trace 327e64ade405e154 ]--- PS. It might happened that it was caused by parition mounted read-only on read-only block device. signature.asc Description: This is a digitally signed message part
