linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: linux-btrfs@vger.kernel.org, Duncan <1i5t5.duncan@cox.net>
Subject: Re: apt taints kernel - btrfs destroys inode
Date: Sun, 8 May 2016 01:11:18 +0200	[thread overview]
Message-ID: <20160507231118.GA19573@angband.pl> (raw)
In-Reply-To: <pan$a8e59$e73b6bd3$47d0e1e7$4518553f@cox.net>

Duncan wrote:
> > btrfs_destroy_inode

> That's a known apparent false-positive warning on current 4.6-rc kernel 
> btrfs.  The destroy-inode bit is related to a file deletion happening in 
> the normal order of things, where this warning code is run, and 
> apparently triggers even under normal operations.

Are you guys reasonably certain it's false-positive?  If so, you _really_
want to disable the warning for 4.6, less than a week from now.  Any
reasonable user of a stable kernel who notices such a warning and stack
dumps will assume something is broken, rightfully panic and consider the
filesystem unsound.

> It's related to some btrfs feature (I think either snapshotting or 
> quotas, but don't recall which) I don't use here so I don't seem the 
> warnings, but there's several threads where people have reported the 
> warnings, so it's apparently quite commonly triggered, but nobody has 
> reported any further problems even where the warnings are coming in the 
> hundreds due to their use-case, so as I said, apparently a false-positive 
> induced by normal operations.

A data point: I've been running for a week with this WARN_ON replaced by a
printk:

--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -9258,7 +9258,8 @@ void btrfs_destroy_inode(struct inode *inode)
        WARN_ON(BTRFS_I(inode)->outstanding_extents);
        WARN_ON(BTRFS_I(inode)->reserved_extents);
        WARN_ON(BTRFS_I(inode)->delalloc_bytes);
-       WARN_ON(BTRFS_I(inode)->csum_bytes);
+       if (BTRFS_I(inode)->csum_bytes)
+               printk("btrfs: btrfs_destroy_inode: WARN csum_bytes\n");
        WARN_ON(BTRFS_I(inode)->defrag_bytes);
 
        /*

and no data loss or anything suspicious so far.  This box has a SSD
(moderate use) and HDD (light use), no RAID, no quotas, compress=lzo, many
subvolumes, 20ish snapshots daily (mostly sbuild for Debian packages).

[~]$ dmesg|grep btrfs_destroy_inode|wc -l
50
[~]$ uptime
 00:17:47 up 1 day, 18:44, 19 users,  load average: 0.23, 0.35, 0.61
[~]$ cat /proc/version 
Linux version 4.6.0-rc6-debug+ (kilobyte@umbar) (gcc version 6.1.1 20160430 (Debian 6.1.1-1) ) #1 SMP Fri May 6 00:33:44 CEST 2016

> I'd expect the warning to be either fixed to only warn when there's an 
> actual issue, or be silenced, by 4.6 release.

In order to get to 4.6 such a commit would need to hit Linus about right
now...


Meow!
-- 
How to exploit the Bible for weight loss:
Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.

  reply	other threads:[~2016-05-07 23:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-01 13:38 apt taints kernel - btrfs destroys inode Jakob Schürz
2016-05-02  0:38 ` Duncan
2016-05-07 23:11   ` Adam Borowski [this message]
2016-05-08  6:31     ` 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=20160507231118.GA19573@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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).