All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: Josef Bacik <josef@redhat.com>,
	linux-btrfs@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/6] btrfs: fix threshold calculation for block groups smaller than 1GB
Date: Mon, 23 Aug 2010 09:22:40 +0800	[thread overview]
Message-ID: <4C71CD60.5050507@cn.fujitsu.com> (raw)
In-Reply-To: <4C71CD4B.10606@cn.fujitsu.com>

If a block group is smaller than 1GB, the extent entry threadhold
calculation will always set the threshold to 0.

So as free space gets fragmented, btrfs will switch to use bitmap
to manage free space, but then will never switch back to extents
due to this bug.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
 fs/btrfs/free-space-cache.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index f488fac..7edbef6 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -263,14 +263,18 @@ static void recalculate_thresholds(struct btrfs_block_group_cache *block_group)
 	u64 max_bytes;
 	u64 bitmap_bytes;
 	u64 extent_bytes;
+	u64 size = block_group->key.offset;
 
 	/*
 	 * The goal is to keep the total amount of memory used per 1gb of space
 	 * at or below 32k, so we need to adjust how much memory we allow to be
 	 * used by extent based free space tracking
 	 */
-	max_bytes = MAX_CACHE_BYTES_PER_GIG *
-		(div64_u64(block_group->key.offset, 1024 * 1024 * 1024));
+	if (size < 1024 * 1024 * 1024)
+		max_bytes = MAX_CACHE_BYTES_PER_GIG;
+	else
+		max_bytes = MAX_CACHE_BYTES_PER_GIG *
+			div64_u64(size, 1024 * 1024 * 1024);
 
 	/*
 	 * we want to account for 1 more bitmap than what we have so we can make
-- 
1.7.0.1

  reply	other threads:[~2010-08-23  1:22 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 ` Li Zefan [this message]
2010-08-23 13:02   ` [PATCH 1/6] btrfs: fix threshold calculation for block groups smaller than 1GB 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
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=4C71CD60.5050507@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.