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.
next prev parent 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).