From: Li Zefan <lizf@cn.fujitsu.com>
To: Josef Bacik <josef@redhat.com>
Cc: Chris Mason <chris.mason@oracle.com>,
linux-btrfs@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] btrfs: check mergeable free space when removing a cluster
Date: Tue, 24 Aug 2010 09:04:13 +0800 [thread overview]
Message-ID: <4C731A8D.2010402@cn.fujitsu.com> (raw)
In-Reply-To: <20100823131504.GE2404@localhost.localdomain>
Josef Bacik wrote:
> On Mon, Aug 23, 2010 at 09:24:07AM +0800, Li Zefan wrote:
>> After returing extents from a cluster to the block group, some
>> extents in the block group may be mergeable.
>>
>> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
>> ---
>> fs/btrfs/free-space-cache.c | 26 ++++++++++++++++++++------
>> 1 files changed, 20 insertions(+), 6 deletions(-)
>>
>> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
>> index faeec8f..c11f4f7 100644
>> --- a/fs/btrfs/free-space-cache.c
>> +++ b/fs/btrfs/free-space-cache.c
>> @@ -234,11 +234,18 @@ tree_search_offset(struct btrfs_block_group_cache *block_group,
>> return entry;
>> }
>>
>> -static void unlink_free_space(struct btrfs_block_group_cache *block_group,
>> - struct btrfs_free_space *info)
>> +static inline void
>> +__unlink_free_space(struct btrfs_block_group_cache *block_group,
>> + struct btrfs_free_space *info)
>> {
>> rb_erase(&info->offset_index, &block_group->free_space_offset);
>> block_group->free_extents--;
>> +}
>> +
>> +static void unlink_free_space(struct btrfs_block_group_cache *block_group,
>> + struct btrfs_free_space *info)
>> +{
>> + __unlink_free_space(block_group, info);
>> block_group->free_space -= info->bytes;
>> }
>>
>> @@ -611,7 +618,7 @@ out:
>> }
>>
>> bool try_merge_free_space(struct btrfs_block_group_cache *block_group,
>> - struct btrfs_free_space *info)
>> + struct btrfs_free_space *info, bool update_stat)
>> {
>> struct btrfs_free_space *left_info;
>> struct btrfs_free_space *right_info;
>> @@ -632,7 +639,10 @@ bool try_merge_free_space(struct btrfs_block_group_cache *block_group,
>> left_info = tree_search_offset(block_group, offset - 1, 0, 0);
>>
>> if (right_info && !right_info->bitmap) {
>> - unlink_free_space(block_group, right_info);
>> + if (update_stat)
>> + unlink_free_space(block_group, right_info);
>> + else
>> + __unlink_free_space(block_group, right_info);
>> info->bytes += right_info->bytes;
>> kfree(right_info);
>> merged = true;
>> @@ -640,7 +650,10 @@ bool try_merge_free_space(struct btrfs_block_group_cache *block_group,
>>
>> if (left_info && !left_info->bitmap &&
>> left_info->offset + left_info->bytes == offset) {
>> - unlink_free_space(block_group, left_info);
>> + if (update_stat)
>> + unlink_free_space(block_group, left_info);
>> + else
>> + __unlink_free_space(block_group, left_info);
>> info->offset = left_info->offset;
>> info->bytes += left_info->bytes;
>> kfree(left_info);
>> @@ -665,7 +678,7 @@ int btrfs_add_free_space(struct btrfs_block_group_cache *block_group,
>>
>> spin_lock(&block_group->tree_lock);
>>
>> - if (try_merge_free_space(block_group, info))
>> + if (try_merge_free_space(block_group, info, true))
>> goto link;
>>
>> /*
>> @@ -883,6 +896,7 @@ __btrfs_return_cluster_to_free_space(
>> node = rb_next(&entry->offset_index);
>> rb_erase(&entry->offset_index, &cluster->root);
>> BUG_ON(entry->bitmap);
>> + try_merge_free_space(block_group, entry, false);
>> tree_insert_offset(&block_group->free_space_offset,
>> entry->offset, &entry->offset_index, 0);
>
> It's early in the morning here, so forgive me if I'm missing something obvious,
> but if try_merge_free_space() succeeds here, then won't tree_insert_offset()
> then add an entry that overlaps the same spot? Should we do something like
>
> merged = try_merge_free_space();
> if (!merged)
> tree_insert_offset();
>
> ? Thanks,
>
In try_merge_free_space() we try to merge the left and right entry into
@entry, and then the caller has to insert the @entry into the tree by
itself.
Similarly, In btrfs_add_free_space() we call link_free_space() no matter
try_merge_free_space() returns success or not.
next prev parent reply other threads:[~2010-08-24 1:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-23 1:22 [PATCH 0/6] btrfs: some bug fixes for free space cache Li Zefan
2010-08-23 1:22 ` [PATCH 1/6] btrfs: fix threshold calculation for block groups smaller than 1GB Li Zefan
2010-08-23 13:02 ` Josef Bacik
2010-08-23 1:23 ` [PATCH 2/6] btrfs: add helper function free_bitmap() Li Zefan
2010-08-23 13:03 ` Josef Bacik
2010-08-23 1:23 ` [PATCH 3/6] btrfs: free fully occupied bitmap in cluster Li Zefan
2010-08-23 13:04 ` Josef Bacik
2010-08-23 1:23 ` [PATCH 4/6] btrfs: update stats when allocating from a cluster Li Zefan
2010-08-23 13:09 ` Josef Bacik
2010-08-24 0:50 ` Li Zefan
2010-08-24 2:50 ` Josef Bacik
2010-08-23 1:23 ` [PATCH 5/6] btrfs: add a helper try_merge_free_space() Li Zefan
2010-08-23 13:15 ` Josef Bacik
2010-08-23 1:24 ` [PATCH 6/6] btrfs: check mergeable free space when removing a cluster Li Zefan
2010-08-23 13:15 ` Josef Bacik
2010-08-24 1:04 ` Li Zefan [this message]
2010-08-24 2:58 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C731A8D.2010402@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=chris.mason@oracle.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.