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 <kilob...@angband.pl>
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
