Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@redhat.com>
To: linux-btrfs@vger.kernel.org
Cc: lt73@cs.drexel.edu
Subject: [PATCH] fix free space accounting when unpinning extents
Date: Wed, 19 Nov 2008 14:56:55 -0500	[thread overview]
Message-ID: <20081119195652.GD16041@unused.rdu.redhat.com> (raw)

Hello,

This patch fixes what I hope is the last early ENOSPC bug left.  I did not know
that pinned extents would merge into one big extent when inserted on to the
pinned extent tree, so I was adding free space to a block group that could
possibly span multiple block groups.  This is a big issue because first that
space doesn't exist in that block group, and second we won't actually use that
space because there are a bunch of other checks to make sure we're allocating
within the constraints of the block group.  This patch fixes the problem by
adding the btrfs_add_free_space to btrfs_update_pinned_extents which makes sure
we are adding the appropriate amount of free space to the appropriate block
group.  Thanks much to Lee Trager for running my myriad of debug patches to help
me track this problem down.  Thank you,

Signed-off-by: Josef Bacik <jbacik@redhat.com>

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index b017e87..e388a37 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2034,6 +2034,8 @@ int btrfs_update_pinned_extents(struct btrfs_root *root,
 			spin_unlock(&cache->lock);
 			spin_unlock(&cache->space_info->lock);
 			fs_info->total_pinned -= len;
+			if (cache->cached)
+				btrfs_add_free_space(cache, bytenr, len);
 		}
 		bytenr += len;
 		num -= len;
@@ -2099,7 +2101,6 @@ int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans,
 	u64 start;
 	u64 end;
 	int ret;
-	struct btrfs_block_group_cache *cache;
 
 	mutex_lock(&root->fs_info->pinned_mutex);
 	while(1) {
@@ -2109,9 +2110,6 @@ int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans,
 			break;
 		btrfs_update_pinned_extents(root, start, end + 1 - start, 0);
 		clear_extent_dirty(unpin, start, end, GFP_NOFS);
-		cache = btrfs_lookup_block_group(root->fs_info, start);
-		if (cache->cached)
-			btrfs_add_free_space(cache, start, end - start + 1);
 		if (need_resched()) {
 			mutex_unlock(&root->fs_info->pinned_mutex);
 			cond_resched();

             reply	other threads:[~2008-11-19 19:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 19:56 Josef Bacik [this message]
2008-11-19 20:49 ` [PATCH] fix free space accounting when unpinning extents Chris Mason

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=20081119195652.GD16041@unused.rdu.redhat.com \
    --to=jbacik@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lt73@cs.drexel.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox