Re: btrfs - kernel warning

2018-02-04 Thread Duncan 
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

2018-02-01 Thread Duncan 
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

Re: btrfs - kernel warning

2018-02-01 Thread Chris Murphy 
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

2018-02-01 Thread Qu Wenruo 


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
>

Re: btrfs - kernel warning

2018-02-01 Thread Chris Murphy 
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

2018-02-01 Thread Chris Murphy 
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

2015-09-15 Thread Duncan 
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

2015-09-15 Thread Austin S Hemmelgarn 

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

Re: btrfs kernel warning

2015-09-15 Thread Austin S Hemmelgarn 

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

Re: btrfs kernel warning

2015-09-15 Thread Austin S Hemmelgarn 

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

Re: btrfs kernel warning

2015-09-15 Thread Tyler Williams 
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