Re: [PATCH 3/5] Btrfs: cleanup for duplicated code in find_free_extent
From: David Sterba <hidden>
Date: 2012-09-14 11:37:06
On Fri, Sep 14, 2012 at 04:58:05PM +0800, Liu Bo wrote:
There is already an 'add free space' phrase in front of this one, we needn't to redo it. Signed-off-by: Liu Bo <redacted>
Yes, the check is duplicate and the values cannot change inbetween,
moreover this calls the add_free_space twice, to it's likely to fix
things (or not, the whole function is a mess and I'm not sticking my
reviewed-by tag).
Also, the return value of btrfs_add_free_space should be checked, as it
may silently fail in case of ENOMEM, and fail loudly if there's failure
in:
btrfs_add_free_space
__btrfs_add_free_space
- either link_free_space
- or insert_into_bitmap
fail with -EEXIST
BUG_ON
I saw the crash inside insert_into_bitmap in logs from yesterday, I
haven't processed them yet, but it looks that it matches this situation.
quoted hunk ↗ jump to hunk
--- fs/btrfs/extent-tree.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index ba58024..6575f89 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c@@ -5806,10 +5806,6 @@ checks: trace_btrfs_reserve_extent(orig_root, block_group, search_start, num_bytes); - if (offset < search_start) - btrfs_add_free_space(used_block_group, offset, - search_start - offset); - BUG_ON(offset > search_start); if (used_block_group != block_group) btrfs_put_block_group(used_block_group); btrfs_put_block_group(block_group);-- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html