path: root/fs/btrfs
diff options
authorChris Mason <chris.mason@oracle.com>2011-11-21 09:39:11 -0500
committerChris Mason <chris.mason@oracle.com>2011-11-21 14:57:33 -0500
commit24a70313969fc3fc440216b40babdb42564acff3 (patch)
tree16c8840f4495369e771cff62bb2fd8aa81d65ee9 /fs/btrfs
parent4d479cf010d56ec9c54f3099992d039918f1296b (diff)
Btrfs: remove free-space-cache.c WARN during log replay
The log replay code only partially loads block groups, since the block group caching code is able to detect and deal with extents the logging code has pinned down. While the logging code is pinning down block groups, there is a bogus WARN_ON we're hitting if the code wasn't able to find an extent in the cache. This commit removes the warning because it can happen any time there isn't a valid free space cache for that block group. Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'fs/btrfs')
1 files changed, 7 insertions, 1 deletions
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index aedacdbf77e..6e5b7e46369 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -1849,7 +1849,13 @@ again:
info = tree_search_offset(ctl, offset_to_bitmap(ctl, offset),
1, 0);
if (!info) {
- WARN_ON(1);
+ /* the tree logging code might be calling us before we
+ * have fully loaded the free space rbtree for this
+ * block group. So it is possible the entry won't
+ * be in the rbtree yet at all. The caching code
+ * will make sure not to put it in the rbtree if
+ * the logging code has pinned it.
+ */
goto out_lock;