[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4b6d66d14e0d502e3109659d9ae4a2d87bfd52e3.1404128998.git.jslaby@suse.cz>
Date: Mon, 30 Jun 2014 13:50:46 +0200
From: Jiri Slaby <jslaby@...e.cz>
To: stable@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Josef Bacik <jbacik@...ionio.com>,
Chris Mason <chris.mason@...ionio.com>,
Jiri Slaby <jslaby@...e.cz>
Subject: [PATCH 3.12 025/181] Btrfs: do not release metadata for space cache inodes
From: Josef Bacik <jbacik@...ionio.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit b6d08f0630d51ec09d67f16f6d7839699bbc0402 upstream.
I've been testing our error paths and I was tripping the BUG_ON() in
drop_outstanding_extent because our outstanding_extents is 0 for space cache
inodes. This is because we don't reserve metadata space for these inodes since
we depend on the global block reserve for our space. To fix this we need to
make sure the DO_ACCOUNTING stuff doesn't actually call release_metadata for
space cache inodes. With this patch I'm no longer panicing. Thanks,
Signed-off-by: Josef Bacik <jbacik@...ionio.com>
Signed-off-by: Chris Mason <chris.mason@...ionio.com>
Signed-off-by: Jiri Slaby <jslaby@...e.cz>
---
fs/btrfs/inode.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 250ed4ef6b91..fa8010c1b628 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1551,7 +1551,13 @@ static void btrfs_clear_bit_hook(struct inode *inode,
spin_unlock(&BTRFS_I(inode)->lock);
}
- if (*bits & EXTENT_DO_ACCOUNTING)
+ /*
+ * We don't reserve metadata space for space cache inodes so we
+ * don't need to call dellalloc_release_metadata if there is an
+ * error.
+ */
+ if (*bits & EXTENT_DO_ACCOUNTING &&
+ root != root->fs_info->tree_root)
btrfs_delalloc_release_metadata(inode, len);
if (root->root_key.objectid != BTRFS_DATA_RELOC_TREE_OBJECTID
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists