Re: btrfs - kernel warning
Duncan posted on Fri, 02 Feb 2018 02:49:52 + as excerpted: > As CMurphy says, 4.11-ish is starting to be reasonable. But you're on > the LTS kernel 4.14 series and userspace 4.14 was developed in parallel, > so btrfs-progs-3.14 would be ideal. Umm... obviously that should be 4.14. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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: btrfs - kernel warning
Qu Wenruo posted on Fri, 02 Feb 2018 09:40:30 +0800 as excerpted: > > On 2018年02月02日 05:06, Patrik Ostrihon wrote: >> Hi, >> >> Today I saw warning in dmesg output. But I don't know what it means. >> Could you help me please? Is it something dangerous for my dato on this >> filesystem? >> >> Thanks >> >> pa3k >> >> root@merkur:~# uname -a >> >> Linux merkur 4.14.8-041408-generic #201712200555 SMP Wed Dec 20 >> 10:57:38 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >> >> root@merkur:~# btrfs --version Btrfs v3.12 >> >> root@merkur:~# btrfs fi show >> >> Label: none uuid: 96f60fa9-c20e-4a13-82b1-9074dd942eab >> Total devices 2 FS bytes used 2.43TiB devid1 size 8.19TiB >> used 2.45TiB path /dev/sdc2 devid2 size 8.19TiB used >> 2.45TiB path /dev/sdd2 >> >> Label: none uuid: 2da0261b-143a-4814-aacb-de46373aebe9 >> Total devices 2 FS bytes used 203.11GiB devid1 size >> 930.00GiB used 206.03GiB path /dev/sdc1 devid2 size >> 930.00GiB used 206.01GiB path /dev/sdd1 >> >> Btrfs v3.12 >> >> >> root@merkur:~# btrfs fi df /usr/local/data >> >> Data, RAID1: total=2.44TiB, used=2.43TiB Data, single: total=8.00MiB, >> used=0.00 System, RAID1: total=8.00MiB, used=368.00KiB System, single: >> total=4.00MiB, used=0.00 Metadata, RAID1: total=5.00GiB, used=3.33GiB >> Metadata, single: total=8.00MiB, used=0.00 unknown, single: >> total=512.00MiB, used=0.00 root@merkur:~# btrfs fi df >> /usr/local/data/hts Data, RAID1: total=205.00GiB, used=202.90GiB Data, >> single: total=8.00MiB, used=0.00 System, RAID1: total=8.00MiB, >> used=48.00KiB System, single: total=4.00MiB, used=0.00 Metadata, RAID1: >> total=1.00GiB, used=213.25MiB Metadata, single: total=8.00MiB, >> used=0.00 unknown, single: total=211.78MiB, used=0.00 >> >> >> [ 4084.704514] [ cut here ] >> [ 4084.704561] WARNING: CPU: 3 PID: 1865 at >> /home/kernel/COD/linux/fs/btrfs/ctree.h:1564 > > This normally means your device size is not aligned to 4K. > > It's normal if your fs has some age as old mkfs.btrfs doesn't align > device size. And... btrfs-progs-3.12, as reported, is _old_, certainly old enough to create both the unaligned filesystem ends, as Qu says here, as well as the unused single-chunks as a remnant of the mkfs.btrfs process, as Chris Murphy says. While in normal btrfs runtime it's the kernel version that's critical, as most runtime commands (balance, scrub...) simply call the appropriate kernel functionality to do the real work, once something goes wrong it's the btrfs-progs userspace tools that do the fixing, and btrfs-progs 3.12 is positively ancient, in btrfs terms. So you _really_ want a newer btrfs-progs if you plan on doing any repairs or the like. As CMurphy says, 4.11-ish is starting to be reasonable. But you're on the LTS kernel 4.14 series and userspace 4.14 was developed in parallel, so btrfs-progs-3.14 would be ideal. That should eliminate similar problems with newly created btrfs, since recent mkfs.btrfs neither creates those unused single chunks during the mkfs process, nor unaligned btrfs ends on the device. > And recently kernel makes the device size alignment check more restrict, > so it will cause such warning. > > > Fortunately btrfs-progs provides offline tool to fix it. > You could use "btrfs rescue fix-device-size " to easily fix it. > And since it's an offline tool, you need to umount your fs first. Again, you'll certainly need something well newer than btrfs-progs 3.12 for that, tho. That's ~4.5 years outdated, right after btrfs officially removed the experimental warnings, and a _LOT_ of bugs (including both of those mentioned here) have been fixed since then! Meanwhile, reemphasizing something CMurphy said as well. I like to point out the sysadmin's first rule of backups: The true value you place on your data is defined not by any arbitrary claims, as those are just words, but rather, by the number of backups you consider it worth the time/trouble/resources to create, of that data. Given that, you can *always* rest easy when something goes wrong and the filesystem won't mount, because regardless of whether you have a backup or not, you /always/ saved what you defined as most important to you, either the data, because it was backed up, or the time/trouble/resources you would have spent on that data has it been of more than the trivial value necessary to make it worth having that backup. Similarly with backup updates, only in the case of updates it's the data in the delta between your last backup and the current state. As soon as the change to your data since the last backup becomes more valuable than the time/trouble/resources necessary to update your backup, you will do so. If you haven't, it simply means you're defining the changes since your last backup as of less value than the time/trouble/resources necessary to do that update, so again, you can *always* rest easy in the face o
Re: btrfs - kernel warning
On Thu, Feb 1, 2018 at 6:40 PM, Qu Wenruo wrote: > Fortunately btrfs-progs provides offline tool to fix it. > You could use "btrfs rescue fix-device-size " to easily fix it. > And since it's an offline tool, you need to umount your fs first. > This feature first appears in btrfs-progs v4.14. -- Chris Murphy -- 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: btrfs - kernel warning
On 2018年02月02日 05:06, Patrik Ostrihon wrote: > Hi, > > Today I saw warning in dmesg output. But I don't know what it means. > Could you help me please? Is it something dangerous for my dato on > this filesystem? > > Thanks > > pa3k > > root@merkur:~# uname -a > > Linux merkur 4.14.8-041408-generic #201712200555 SMP Wed Dec 20 > 10:57:38 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > > root@merkur:~# btrfs --version > Btrfs v3.12 > > root@merkur:~# btrfs fi show > > Label: none uuid: 96f60fa9-c20e-4a13-82b1-9074dd942eab > Total devices 2 FS bytes used 2.43TiB > devid1 size 8.19TiB used 2.45TiB path /dev/sdc2 > devid2 size 8.19TiB used 2.45TiB path /dev/sdd2 > > Label: none uuid: 2da0261b-143a-4814-aacb-de46373aebe9 > Total devices 2 FS bytes used 203.11GiB > devid1 size 930.00GiB used 206.03GiB path /dev/sdc1 > devid2 size 930.00GiB used 206.01GiB path /dev/sdd1 > > Btrfs v3.12 > > > root@merkur:~# btrfs fi df /usr/local/data > > Data, RAID1: total=2.44TiB, used=2.43TiB > Data, single: total=8.00MiB, used=0.00 > System, RAID1: total=8.00MiB, used=368.00KiB > System, single: total=4.00MiB, used=0.00 > Metadata, RAID1: total=5.00GiB, used=3.33GiB > Metadata, single: total=8.00MiB, used=0.00 > unknown, single: total=512.00MiB, used=0.00 > root@merkur:~# btrfs fi df /usr/local/data/hts > Data, RAID1: total=205.00GiB, used=202.90GiB > Data, single: total=8.00MiB, used=0.00 > System, RAID1: total=8.00MiB, used=48.00KiB > System, single: total=4.00MiB, used=0.00 > Metadata, RAID1: total=1.00GiB, used=213.25MiB > Metadata, single: total=8.00MiB, used=0.00 > unknown, single: total=211.78MiB, used=0.00 > > > [ 4084.704514] [ cut here ] > [ 4084.704561] WARNING: CPU: 3 PID: 1865 at > /home/kernel/COD/linux/fs/btrfs/ctree.h:1564 This normally means your device size is not aligned to 4K. It's normal if your fs has some age as old mkfs.btrfs doesn't align device size. And recently kernel makes the device size alignment check more restrict, so it will cause such warning. Fortunately btrfs-progs provides offline tool to fix it. You could use "btrfs rescue fix-device-size " to easily fix it. And since it's an offline tool, you need to umount your fs first. Thanks, Qu > btrfs_update_device+0x1be/0x1d0 [btrfs] > [ 4084.704562] Modules linked in: snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic gpio_ich intel_powerclamp > coretemp mxl5xx i915 kvm_intel kvm video drm_kms_helper ftdi_sio drm > usbserial joydev irqbypass input_leds intel_cstate snd_hda_intel > snd_hda_codec snd_hda_core ddbridge snd_hwdep i2c_algo_bit snd_pcm > snd_timer fb_sys_fops syscopyarea snd cxd2099(C) sysfillrect soundcore > sysimgblt dvb_core lpc_ich mei_me nuvoton_cir mei mac_hid rc_core > shpchp 8021q garp mrp stp llc lp parport btrfs zstd_compress raid10 > raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor > hid_generic e1000e usbhid uas ptp raid6_pq usb_storage hid libcrc32c > pps_core pata_acpi raid1 raid0 multipath linear > [ 4084.704598] CPU: 3 PID: 1865 Comm: btrfs-cleaner Tainted: G > C 4.14.8-041408-generic #201712200555 > [ 4084.704598] Hardware name: /DH57JG, BIOS > JGIBX10J.86A.0663.2011.1019.0408 10/19/2011 > [ 4084.704599] task: 9803b17f8000 task.stack: a6f2822f > [ 4084.704616] RIP: 0010:btrfs_update_device+0x1be/0x1d0 [btrfs] > [ 4084.704617] RSP: 0018:a6f2822f3d40 EFLAGS: 00010206 > [ 4084.704618] RAX: 0fff RBX: 9803b38bf9a0 RCX: > 082f6e00 > [ 4084.704619] RDX: 1000 RSI: 3f5c RDI: > 980397b574c8 > [ 4084.704619] RBP: a6f2822f3d88 R08: a6f2822f3cf0 R09: > a6f2822f3cf8 > [ 4084.704620] R10: 1000 R11: 3000 R12: > 980375d41000 > [ 4084.704621] R13: R14: 3f3c R15: > 980397b574c8 > [ 4084.704622] FS: () GS:9803b72c() > knlGS: > [ 4084.704623] CS: 0010 DS: ES: CR0: 80050033 > [ 4084.704624] CR2: 7f883404d000 CR3: 1fa09003 CR4: > 000206e0 > [ 4084.704625] Call Trace: > [ 4084.704644] btrfs_remove_chunk+0x365/0x870 [btrfs] > [ 4084.704658] btrfs_delete_unused_bgs+0x320/0x3c0 [btrfs] > [ 4084.704672] cleaner_kthread+0x159/0x170 [btrfs] > [ 4084.704676] kthread+0x125/0x140 > [ 4084.704689] ? __btree_submit_bio_start+0x20/0x20 [btrfs] > [ 4084.704691] ? kthread_create_on_node+0x70/0x70 > [ 4084.704694] ret_from_fork+0x25/0x30 > [ 4084.704695] Code: 4c 89 ff 45 31 c0 ba 10 00 00 00 4c 89 f6 e8 1a > 20 ff ff 4c 89 ff e8 82 ea fc ff e9 d3 fe ff ff 41 bd f4 ff ff ff e9 > d0 fe ff ff <0f> ff eb b6 e8 c9 15 9e de 66 0f 1f 84 00 00 00 00 00 66 > 66 66 > [ 4084.704717] ---[ end trace 4a9fc911d4199609 ]--- > [ 4084.705475] [ cut here ] > [ 4084.705516] WARNING: CPU: 2 PID: 1865 at > /home/kernel/COD/linux/fs/btrfs/ctree.h:1564 > bt
Re: btrfs - kernel warning
Oh and to be super clear, do not use --repair with 'btrfs check' until there's a dev recommendation to try it. It should be safe, but is still sometimes fragile in the multiple device case. --- Chris Murphy -- 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: btrfs - kernel warning
On Thu, Feb 1, 2018 at 2:06 PM, Patrik Ostrihon wrote: > Hi, > > Today I saw warning in dmesg output. But I don't know what it means. > Could you help me please? Is it something dangerous for my dato on > this filesystem? Is this a persistent warning you're getting or is it a one time message? Looks like it's happening when deallocating empty block groups. I'm not sure why, but I also can't tell from the call trace which of the two Btrfs file systems it's referring to. Anyway, what I would do in order: a. Backups. Your post suggests you're worried about your data, so first order of business is to update the backups. Raid1 is not a backup. b. I'd find a relatively recent live, so that it has a relatively recent btrfs-progs, v4.11.3 or newer. Create USB stick media to boot from and run the following commands on both volumes (pick one of the two drives for each Btrfs volume; it is not a per drive check it is a per volume check and it doesn't matter which of the two drives you pick). btrfs check btrfs check --mode=lowmem The lowmem mode is a different implementation and sometimes there are different results. c. You only posted the df output for one of the two file systems. The one you posted is not completely raid1, you have some single chunks which don't appear to be used but that they're present can impact the ability to mount degraded (i.e. degraded mount might fail in this condition) btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /usr/local/data That will leave existing raid1 block groups untouched and will effectively remove the unused single chunks. You should check the other volume and make sure all block groups are raid1. -- Chris Murphy -- 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: btrfs kernel warning
Austin S Hemmelgarn posted on Tue, 15 Sep 2015 14:46:28 -0400 as excerpted: > On 2015-09-15 14:42, Tyler Williams wrote: >> So I only had qgroups enabled because at some point it seemed like it >> gave me the size of individual snapshots. Would it be likely that if I >> just removed qgroups from that volume that would prevent that message >> in the future? >> > Maybe, I'm not entirely certain if disabling qgroups on a volume removes > the qgroup metadata, and if the metadata is still there, it might still > cause issues. It's worth trying though because it shouldn't make > anything worse than it already is. Confirming the two-step, disabling unlikely to do it without removal... I'm not a quota/qgroup user either, but FWIW, after someone else reported problems (in that case, performance related) that I suspected were quota related, as they ultimately turned out to be, he did say that simply disabling quotas wasn't enough, he had to delete the quota tracking metadata to eliminate the issue. Without personal btrfs quota feature experience I can't supply details as to what that involves, but he did specifically mention that simply disabling them didn't solve the problem, while removing them did. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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: btrfs kernel warning
Fantastic. Thanks a ton On Tue, Sep 15, 2015 at 1:03 PM, Austin S Hemmelgarn wrote: > On 2015-09-15 14:53, Tyler Williams wrote: >> >> I'll give that a shot. This will be a lame questions, but what address >> to I need to reply to for these messages to make it to the mailing >> list? It looks like I'm replying to you instead of to the mailing list >> itself. Thanks > > It's not a lame question at all, it's a very sensible one. > The easy option is to use 'Reply All' or 'Reply List' if your e-mail client > supports it. For some rather stupid reason, some mail clients don't support > this properly, in which case you have to use the regular Reply button and > add in the rest of the To and Cc addresses from the original mail (and then > optionally complain to the developers of your e-mail client that it doesn't > support functionality that's been standard since before the year 2000). > >> On Tue, Sep 15, 2015 at 12:46 PM, Austin S Hemmelgarn >> wrote: >>> >>> On 2015-09-15 14:42, Tyler Williams wrote: So I only had qgroups enabled because at some point it seemed like it gave me the size of individual snapshots. Would it be likely that if I just removed qgroups from that volume that would prevent that message in the future? >>> Maybe, I'm not entirely certain if disabling qgroups on a volume removes >>> the >>> qgroup metadata, and if the metadata is still there, it might still cause >>> issues. It's worth trying though because it shouldn't make anything >>> worse >>> than it already is. >>> On Tue, Sep 15, 2015 at 12:32 PM, Austin S Hemmelgarn wrote: > > > On 2015-09-15 14:13, Tyler Williams wrote: >> >> >> >> I've received several kernel warnings over the last few weeks. I >> checked on the #BTRFS irc channel and it was suggested that I post the >> relevant information here to see if this was something that I should >> be worried about. >> >> >> [root@tawilliams ~]# uname -a >> Linux tawilliams.williamstlr.net 4.1.6-201.fc22.x86_64 #1 SMP Fri Sep >> 4 17:49:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> >> [root@tawilliams ~]# btrfs --version >> btrfs-progs v4.1 >> >> >> [root@tawilliams ~]# btrfs fi sh >> Label: 'fedora' uuid: 1e37c117-d493-4d3e-a585-46b90de16569 >>Total devices 1 FS bytes used 3.70GiB >>devid1 size 47.31GiB used 6.04GiB path /dev/sda4 >> >> Label: none uuid: f9b38a56-44d4-4974-9640-95341bd8ae6a >>Total devices 1 FS bytes used 424.23GiB >>devid1 size 931.51GiB used 428.04GiB path /dev/sdc1 >> >> Label: none uuid: 5266d71b-1d75-4b28-accc-95187f2d65a4 >>Total devices 1 FS bytes used 889.09GiB >>devid1 size 931.50GiB used 892.03GiB path /dev/sdb2 >> >> Label: 'tawilliams' uuid: 142b1866-f5e1-48b0-acd3-401e8eb4d219 >>Total devices 2 FS bytes used 1.10TiB >>devid1 size 1.82TiB used 1.16TiB path /dev/sdb1 >>devid2 size 1.82TiB used 1.16TiB path /dev/sde >> >> Label: 'fedora-server' uuid: a5a82150-7ff3-43d4-a86b-a7f9d2df3737 >>Total devices 1 FS bytes used 27.09GiB >>devid1 size 47.51GiB used 38.81GiB path /dev/sdd3 >> >> btrfs-progs v4.1 >> >> [root@tawilliams ~]# btrfs fi df /media/btrfs-raid1/ >> Data, RAID1: total=1.16TiB, used=1.10TiB >> System, RAID1: total=32.00MiB, used=208.00KiB >> Metadata, RAID1: total=5.00GiB, used=3.86GiB >> GlobalReserve, single: total=512.00MiB, used=0.00B >> >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [ cut >> here ] >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: WARNING: CPU: 0 >> PID: 544 at fs/btrfs/qgroup.c:1028 >> __qgroup_excl_accounting+0x1cf/0x260 [btrfs]() >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Modules linked in: >> nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter >> ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute >> bridg >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: CPU: 0 PID: 544 >> Comm: btrfs-cleaner Not tainted 4.1.6-201.fc22.x86_64 #1 >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Hardware name: >> Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V >> UEFI Release v1.0 11/26/2012 >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: >> 5a7148da 8800383f7b38 81799a6d >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: >> 8800383f7b78 810a165a >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: >> 880036e71048 880022079960 c000 >> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Call Trace: >> Sep 15 10:45:16 ta
Re: btrfs kernel warning
On 2015-09-15 14:53, Tyler Williams wrote: I'll give that a shot. This will be a lame questions, but what address to I need to reply to for these messages to make it to the mailing list? It looks like I'm replying to you instead of to the mailing list itself. Thanks It's not a lame question at all, it's a very sensible one. The easy option is to use 'Reply All' or 'Reply List' if your e-mail client supports it. For some rather stupid reason, some mail clients don't support this properly, in which case you have to use the regular Reply button and add in the rest of the To and Cc addresses from the original mail (and then optionally complain to the developers of your e-mail client that it doesn't support functionality that's been standard since before the year 2000). On Tue, Sep 15, 2015 at 12:46 PM, Austin S Hemmelgarn wrote: On 2015-09-15 14:42, Tyler Williams wrote: So I only had qgroups enabled because at some point it seemed like it gave me the size of individual snapshots. Would it be likely that if I just removed qgroups from that volume that would prevent that message in the future? Maybe, I'm not entirely certain if disabling qgroups on a volume removes the qgroup metadata, and if the metadata is still there, it might still cause issues. It's worth trying though because it shouldn't make anything worse than it already is. On Tue, Sep 15, 2015 at 12:32 PM, Austin S Hemmelgarn wrote: On 2015-09-15 14:13, Tyler Williams wrote: I've received several kernel warnings over the last few weeks. I checked on the #BTRFS irc channel and it was suggested that I post the relevant information here to see if this was something that I should be worried about. [root@tawilliams ~]# uname -a Linux tawilliams.williamstlr.net 4.1.6-201.fc22.x86_64 #1 SMP Fri Sep 4 17:49:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@tawilliams ~]# btrfs --version btrfs-progs v4.1 [root@tawilliams ~]# btrfs fi sh Label: 'fedora' uuid: 1e37c117-d493-4d3e-a585-46b90de16569 Total devices 1 FS bytes used 3.70GiB devid1 size 47.31GiB used 6.04GiB path /dev/sda4 Label: none uuid: f9b38a56-44d4-4974-9640-95341bd8ae6a Total devices 1 FS bytes used 424.23GiB devid1 size 931.51GiB used 428.04GiB path /dev/sdc1 Label: none uuid: 5266d71b-1d75-4b28-accc-95187f2d65a4 Total devices 1 FS bytes used 889.09GiB devid1 size 931.50GiB used 892.03GiB path /dev/sdb2 Label: 'tawilliams' uuid: 142b1866-f5e1-48b0-acd3-401e8eb4d219 Total devices 2 FS bytes used 1.10TiB devid1 size 1.82TiB used 1.16TiB path /dev/sdb1 devid2 size 1.82TiB used 1.16TiB path /dev/sde Label: 'fedora-server' uuid: a5a82150-7ff3-43d4-a86b-a7f9d2df3737 Total devices 1 FS bytes used 27.09GiB devid1 size 47.51GiB used 38.81GiB path /dev/sdd3 btrfs-progs v4.1 [root@tawilliams ~]# btrfs fi df /media/btrfs-raid1/ Data, RAID1: total=1.16TiB, used=1.10TiB System, RAID1: total=32.00MiB, used=208.00KiB Metadata, RAID1: total=5.00GiB, used=3.86GiB GlobalReserve, single: total=512.00MiB, used=0.00B Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [ cut here ] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: WARNING: CPU: 0 PID: 544 at fs/btrfs/qgroup.c:1028 __qgroup_excl_accounting+0x1cf/0x260 [btrfs]() Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridg Sep 15 10:45:16 tawilliams.williamstlr.net kernel: CPU: 0 PID: 544 Comm: btrfs-cleaner Not tainted 4.1.6-201.fc22.x86_64 #1 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 5a7148da 8800383f7b38 81799a6d Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 8800383f7b78 810a165a Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 880036e71048 880022079960 c000 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Call Trace: Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] dump_stack+0x45/0x57 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] warn_slowpath_common+0x8a/0xc0 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] warn_slowpath_null+0x1a/0x20 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] __qgroup_excl_accounting+0x1cf/0x260 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_delayed_qgroup_accounting+0x2dc/0xc70 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? walk_up_proc+0xd7/0x500 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_run_delayed_refs.part.68+0x20f/0x280 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrf
Re: btrfs kernel warning
On 2015-09-15 14:42, Tyler Williams wrote: So I only had qgroups enabled because at some point it seemed like it gave me the size of individual snapshots. Would it be likely that if I just removed qgroups from that volume that would prevent that message in the future? Maybe, I'm not entirely certain if disabling qgroups on a volume removes the qgroup metadata, and if the metadata is still there, it might still cause issues. It's worth trying though because it shouldn't make anything worse than it already is. On Tue, Sep 15, 2015 at 12:32 PM, Austin S Hemmelgarn wrote: On 2015-09-15 14:13, Tyler Williams wrote: I've received several kernel warnings over the last few weeks. I checked on the #BTRFS irc channel and it was suggested that I post the relevant information here to see if this was something that I should be worried about. [root@tawilliams ~]# uname -a Linux tawilliams.williamstlr.net 4.1.6-201.fc22.x86_64 #1 SMP Fri Sep 4 17:49:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@tawilliams ~]# btrfs --version btrfs-progs v4.1 [root@tawilliams ~]# btrfs fi sh Label: 'fedora' uuid: 1e37c117-d493-4d3e-a585-46b90de16569 Total devices 1 FS bytes used 3.70GiB devid1 size 47.31GiB used 6.04GiB path /dev/sda4 Label: none uuid: f9b38a56-44d4-4974-9640-95341bd8ae6a Total devices 1 FS bytes used 424.23GiB devid1 size 931.51GiB used 428.04GiB path /dev/sdc1 Label: none uuid: 5266d71b-1d75-4b28-accc-95187f2d65a4 Total devices 1 FS bytes used 889.09GiB devid1 size 931.50GiB used 892.03GiB path /dev/sdb2 Label: 'tawilliams' uuid: 142b1866-f5e1-48b0-acd3-401e8eb4d219 Total devices 2 FS bytes used 1.10TiB devid1 size 1.82TiB used 1.16TiB path /dev/sdb1 devid2 size 1.82TiB used 1.16TiB path /dev/sde Label: 'fedora-server' uuid: a5a82150-7ff3-43d4-a86b-a7f9d2df3737 Total devices 1 FS bytes used 27.09GiB devid1 size 47.51GiB used 38.81GiB path /dev/sdd3 btrfs-progs v4.1 [root@tawilliams ~]# btrfs fi df /media/btrfs-raid1/ Data, RAID1: total=1.16TiB, used=1.10TiB System, RAID1: total=32.00MiB, used=208.00KiB Metadata, RAID1: total=5.00GiB, used=3.86GiB GlobalReserve, single: total=512.00MiB, used=0.00B Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [ cut here ] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: WARNING: CPU: 0 PID: 544 at fs/btrfs/qgroup.c:1028 __qgroup_excl_accounting+0x1cf/0x260 [btrfs]() Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridg Sep 15 10:45:16 tawilliams.williamstlr.net kernel: CPU: 0 PID: 544 Comm: btrfs-cleaner Not tainted 4.1.6-201.fc22.x86_64 #1 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 5a7148da 8800383f7b38 81799a6d Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 8800383f7b78 810a165a Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 880036e71048 880022079960 c000 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Call Trace: Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] dump_stack+0x45/0x57 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] warn_slowpath_common+0x8a/0xc0 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] warn_slowpath_null+0x1a/0x20 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] __qgroup_excl_accounting+0x1cf/0x260 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_delayed_qgroup_accounting+0x2dc/0xc70 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? walk_up_proc+0xd7/0x500 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_run_delayed_refs.part.68+0x20f/0x280 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_run_delayed_refs+0x15/0x30 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_should_end_transaction+0x5a/0x60 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_drop_snapshot+0x455/0x8a0 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? btrfs_kill_all_delayed_nodes+0x5c/0x110 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? btrfs_run_defrag_inodes+0x29f/0x360 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_clean_one_deleted_snapshot+0xb2/0x110 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] cleaner_kthread+0xb5/0x1b0 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? check_leaf+0x380/0x380 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] kthread+0xd8/0xf0 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? kthread_worker_f
Re: btrfs kernel warning
On 2015-09-15 14:13, Tyler Williams wrote: I've received several kernel warnings over the last few weeks. I checked on the #BTRFS irc channel and it was suggested that I post the relevant information here to see if this was something that I should be worried about. [root@tawilliams ~]# uname -a Linux tawilliams.williamstlr.net 4.1.6-201.fc22.x86_64 #1 SMP Fri Sep 4 17:49:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@tawilliams ~]# btrfs --version btrfs-progs v4.1 [root@tawilliams ~]# btrfs fi sh Label: 'fedora' uuid: 1e37c117-d493-4d3e-a585-46b90de16569 Total devices 1 FS bytes used 3.70GiB devid1 size 47.31GiB used 6.04GiB path /dev/sda4 Label: none uuid: f9b38a56-44d4-4974-9640-95341bd8ae6a Total devices 1 FS bytes used 424.23GiB devid1 size 931.51GiB used 428.04GiB path /dev/sdc1 Label: none uuid: 5266d71b-1d75-4b28-accc-95187f2d65a4 Total devices 1 FS bytes used 889.09GiB devid1 size 931.50GiB used 892.03GiB path /dev/sdb2 Label: 'tawilliams' uuid: 142b1866-f5e1-48b0-acd3-401e8eb4d219 Total devices 2 FS bytes used 1.10TiB devid1 size 1.82TiB used 1.16TiB path /dev/sdb1 devid2 size 1.82TiB used 1.16TiB path /dev/sde Label: 'fedora-server' uuid: a5a82150-7ff3-43d4-a86b-a7f9d2df3737 Total devices 1 FS bytes used 27.09GiB devid1 size 47.51GiB used 38.81GiB path /dev/sdd3 btrfs-progs v4.1 [root@tawilliams ~]# btrfs fi df /media/btrfs-raid1/ Data, RAID1: total=1.16TiB, used=1.10TiB System, RAID1: total=32.00MiB, used=208.00KiB Metadata, RAID1: total=5.00GiB, used=3.86GiB GlobalReserve, single: total=512.00MiB, used=0.00B Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [ cut here ] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: WARNING: CPU: 0 PID: 544 at fs/btrfs/qgroup.c:1028 __qgroup_excl_accounting+0x1cf/0x260 [btrfs]() Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridg Sep 15 10:45:16 tawilliams.williamstlr.net kernel: CPU: 0 PID: 544 Comm: btrfs-cleaner Not tainted 4.1.6-201.fc22.x86_64 #1 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 5a7148da 8800383f7b38 81799a6d Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 8800383f7b78 810a165a Sep 15 10:45:16 tawilliams.williamstlr.net kernel: 880036e71048 880022079960 c000 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Call Trace: Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] dump_stack+0x45/0x57 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] warn_slowpath_common+0x8a/0xc0 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] warn_slowpath_null+0x1a/0x20 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] __qgroup_excl_accounting+0x1cf/0x260 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_delayed_qgroup_accounting+0x2dc/0xc70 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? walk_up_proc+0xd7/0x500 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_run_delayed_refs.part.68+0x20f/0x280 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_run_delayed_refs+0x15/0x30 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_should_end_transaction+0x5a/0x60 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_drop_snapshot+0x455/0x8a0 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? btrfs_kill_all_delayed_nodes+0x5c/0x110 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? btrfs_run_defrag_inodes+0x29f/0x360 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] btrfs_clean_one_deleted_snapshot+0xb2/0x110 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] cleaner_kthread+0xb5/0x1b0 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? check_leaf+0x380/0x380 [btrfs] Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] kthread+0xd8/0xf0 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? kthread_worker_fn+0x180/0x180 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ret_from_fork+0x42/0x70 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: [] ? kthread_worker_fn+0x180/0x180 Sep 15 10:45:16 tawilliams.williamstlr.net kernel: ---[ end trace e8c2f252933902d6 ]--- While I can't provide any advice as to whether this is something to be worried about or not, I would like to point out that even in recent kernel versions, there are multiple known issues in the qgroup code. I don't think there's anything currently known on 4.1.6 that has the possibility of eating your data, but I am by no