Mailinglist Archive: opensuse-bugs (4652 mails)

< Previous Next >
[Bug 1043912] kernel 4.4.70-18.9-default is unable to mount some btrfs partitions, unlike previous kernel
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Tue, 27 Jun 2017 07:22:17 +0000
  • Message-id: <bug-1043912-21960-Phw65CtqBg@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=1043912
http://bugzilla.suse.com/show_bug.cgi?id=1043912#c20

--- Comment #20 from Nikolay Borisov <nborisov@xxxxxxxx> ---
(In reply to Frederic Crozat from comment #0)
Latest maintenance update on kernel (4.4.70-18.9-default) is causing one of
my btrfs partition to not be mountable at all:

[ 4.125164] BTRFS info (device sdb1): disk space caching is enabled
[ 4.132807] BTRFS error (device sdb1): super_total_bytes 1000203816960
mismatch with fs_devices total_rw_bytes 1000203820544
[ 4.132809] BTRFS error (device sdb1): failed to read chunk tree: -22
[ 4.169764] BTRFS error (device sdb1): open_ctree failed

kernel-default-4.4.62-18.6.1.x86_64 is able to mount it properly.

I ran scrub and balance on it from kernel 4.4.62-18.6.1, no error found :
Checking filesystem on /dev/sdb1
UUID: 072539d3-94cc-4c96-b50d-448c5b223850
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 409700515840 bytes used, no error found
total csum bytes: 399474044
total tree bytes: 536072192
total fs tree bytes: 60981248
total extent tree bytes: 20795392
btree space waste bytes: 55480247
file data blocks allocated: 409166581760
referenced 409166577664

(In reply to Frederic Crozat from comment #19)
(In reply to Nikolay Borisov from comment #18)
I've built yet another kernel off latest 42.2, it can be found here:
https://build.suse.de/project/show/home:nikbor:bsc1043912


It contains a patch which rounds down the values used in the check and
should hopefully allow Frederic to mount his system. If everything checks
out I will commit it.

I can confirm kernel 4.4.73-1.g16a5f2a-default properly mounts my
"problematic" btrfs partition

However, I got the following warning (not sure if it is related):

[ 54.116369] WARNING: CPU: 0 PID: 278 at ../fs/btrfs/ctree.h:1513
btrfs_update_device+0x1ad/0x1c0 [btrfs]()
[ 54.116398] ath9k_hw gpio_ich snd_hda_core snd_hwdep snd_pcm_oss
iTCO_wdt iTCO_vendor_support lrw gf128mul ath r8169 snd_pcm mac80211 joydev
glue_helper mii ablk_helper lpc_ich mfd_core snd_seq cfg80211 rfkill fjes
snd_seq_device snd_timer snd_mixer_oss processor i2c_i801 snd cryptd mei_me
shpchp mei soundcore pcspkr btrfs xor hid_microsoft hid_generic usbhid
raid6_pq sr_mod cdrom sd_mod crc32c_intel ahci libahci i915 libata video
i2c_algo_bit xhci_pci drm_kms_helper ehci_pci syscopyarea sysfillrect
xhci_hcd sysimgblt ehci_hcd fb_sys_fops usbcore drm usb_common button sg
dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod efivarfs
autofs4
[ 54.116438] Workqueue: events_unbound btrfs_async_reclaim_metadata_space
[btrfs]
[ 54.116490] [<ffffffffa04c66fd>] btrfs_update_device+0x1ad/0x1c0 [btrfs]
[ 54.116512] [<ffffffffa04cbf91>] btrfs_finish_chunk_alloc+0x151/0x590
[btrfs]
[ 54.116521] [<ffffffffa04875c7>]
btrfs_create_pending_block_groups+0x137/0x280 [btrfs]
[ 54.116539] [<ffffffffa049ff53>] __btrfs_end_transaction+0x93/0x350
[btrfs]
[ 54.116548] [<ffffffffa0488b6f>] flush_space+0xef/0x5f0 [btrfs]
[ 54.116557] [<ffffffffa048918b>]
btrfs_async_reclaim_metadata_space+0x11b/0x4b0 [btrfs]
[ 54.117794] WARNING: CPU: 0 PID: 278 at ../fs/btrfs/ctree.h:1513
btrfs_update_device+0x1ad/0x1c0 [btrfs]()
[ 54.117819] gpio_ich snd_hda_core snd_hwdep snd_pcm_oss iTCO_wdt
iTCO_vendor_support lrw gf128mul ath r8169 snd_pcm mac80211 joydev
glue_helper mii ablk_helper lpc_ich mfd_core snd_seq cfg80211 rfkill fjes
snd_seq_device snd_timer snd_mixer_oss processor i2c_i801 snd cryptd mei_me
shpchp mei soundcore pcspkr btrfs xor hid_microsoft hid_generic usbhid
raid6_pq sr_mod cdrom sd_mod crc32c_intel ahci libahci i915 libata video
i2c_algo_bit xhci_pci drm_kms_helper ehci_pci syscopyarea sysfillrect
xhci_hcd sysimgblt ehci_hcd fb_sys_fops usbcore drm usb_common button sg
dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod efivarfs
autofs4
[ 54.117855] Workqueue: events_unbound btrfs_async_reclaim_metadata_space
[btrfs]
[ 54.117884] [<ffffffffa04c66fd>] btrfs_update_device+0x1ad/0x1c0 [btrfs]
[ 54.117896] [<ffffffffa04cbf91>] btrfs_finish_chunk_alloc+0x151/0x590
[btrfs]
[ 54.117905] [<ffffffffa04875c7>]
btrfs_create_pending_block_groups+0x137/0x280 [btrfs]
[ 54.117915] [<ffffffffa049ff53>] __btrfs_end_transaction+0x93/0x350
[btrfs]
[ 54.117925] [<ffffffffa0488b6f>] flush_space+0xef/0x5f0 [btrfs]
[ 54.117933] [<ffffffffa048918b>]
btrfs_async_reclaim_metadata_space+0x11b/0x4b0 [btrfs]

So yeah, the warning comes from newly-added code whose purpose is to catch
offenders which try to store a non-rounded-down value. Your case is such. It's
not critical and might actually go away if you run a rebalance operation on
this volume, could you actually try this?

So at this point there are two things I can do:

1. Put a round_down call in btrfs_update_device this would mean we will likely
never trigger the warning and thus won't catch further offenders, yet this
won't cause any problems since we are going to always be storing rounded down
values.

2. Apply the patch which does rounding down of the error check values so it
doesn't prevent mounts but we will at least be getting warnings when encounter
non rounded values.

Personally I'm more inclined to go with option 2. Jeff what's your take on that
?

--
You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >