This happens a lot on real-world loads. The issue is apparently benign, as unsaved pending checksums are moot when the ship^Winode is going down anyway. Thus, no need to cause panic in users. I've retained the warning in CONFIG_BTRFS_ASSERT builds, as this shouldn't happen. I've replaced the no longer helpful register+stack dump with a printk that mentions the device affected. Signed-off-by: Adam Borowski <kilobyte@xxxxxxxxxx> --- fs/btrfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 2aaba58..ed78104 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9258,7 +9258,10 @@ 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); +#ifdef CONFIG_BTRFS_ASSERT + if (BTRFS_I(inode)->csum_bytes) + btrfs_info(root->fs_info, "btrfs_destroy_inode: leftover csum_bytes"); +#endif WARN_ON(BTRFS_I(inode)->defrag_bytes); /* -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
