linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Tyler Williams <williams.tlr@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs kernel warning
Date: Tue, 15 Sep 2015 14:32:31 -0400	[thread overview]
Message-ID: <55F8643F.5070701@gmail.com> (raw)
In-Reply-To: <CALq_kZHBx8hR_6kfwYgJChdK2RKw1+up07pGGYe+RRGOb2rhKA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5928 bytes --]

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
>          devid    1 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
>          devid    1 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
>          devid    1 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
>          devid    1 size 1.82TiB used 1.16TiB path /dev/sdb1
>          devid    2 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
>          devid    1 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:  0000000000000000
> 000000005a7148da ffff8800383f7b38 ffffffff81799a6d
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:  0000000000000000
> 0000000000000000 ffff8800383f7b78 ffffffff810a165a
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:  0000000000000000
> ffff880036e71048 ffff880022079960 ffffffffffffc000
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel: Call Trace:
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff81799a6d>] dump_stack+0x45/0x57
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff810a165a>] warn_slowpath_common+0x8a/0xc0
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff810a178a>] warn_slowpath_null+0x1a/0x20
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa01341af>] __qgroup_excl_accounting+0x1cf/0x260 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa01372ec>] btrfs_delayed_qgroup_accounting+0x2dc/0xc70
> [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00b6a67>] ? walk_up_proc+0xd7/0x500 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00ba85f>] btrfs_run_delayed_refs.part.68+0x20f/0x280
> [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00ba8e5>] btrfs_run_delayed_refs+0x15/0x30 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00cb68a>] btrfs_should_end_transaction+0x5a/0x60 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00b8c85>] btrfs_drop_snapshot+0x455/0x8a0 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa01276cc>] ? btrfs_kill_all_delayed_nodes+0x5c/0x110 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00df11f>] ? btrfs_run_defrag_inodes+0x29f/0x360 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00cbb82>] btrfs_clean_one_deleted_snapshot+0xb2/0x110
> [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00c3dc5>] cleaner_kthread+0xb5/0x1b0 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffffa00c3d10>] ? check_leaf+0x380/0x380 [btrfs]
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff810c0bf8>] kthread+0xd8/0xf0
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff810c0b20>] ? kthread_worker_fn+0x180/0x180
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff817a0422>] ret_from_fork+0x42/0x70
> Sep 15 10:45:16 tawilliams.williamstlr.net kernel:
> [<ffffffff810c0b20>] ? 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 means an expert on this 
particular subject (I don't use quotas on most of my systems, and for 
those that I do, I just use separate thinly-provisioned partitions for 
the individual quota users (which in turn makes things much easier for 
everyone involved)).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-09-15 18:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15 18:13 btrfs kernel warning Tyler Williams
2015-09-15 18:32 ` Austin S Hemmelgarn [this message]
     [not found]   ` <CALq_kZGHM2D7-XhrMbkhik2Hn=CWJGPBjbGrJWqS32k7nQEZ3g@mail.gmail.com>
2015-09-15 18:46     ` Austin S Hemmelgarn
     [not found]       ` <CALq_kZEf9q9Lrbk32qKhdeuE4B=X2nah9Db9YmD6Y5Xk_Fg32w@mail.gmail.com>
2015-09-15 19:03         ` Austin S Hemmelgarn
2015-09-15 19:12           ` Tyler Williams
2015-09-16  4:09       ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55F8643F.5070701@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=williams.tlr@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).