aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2009-11-10 21:23:48 -0500
committerChris Mason <chris.mason@oracle.com>2009-11-11 14:20:17 -0500
commit01dea1efc23b511d3b58bb94da07ddb6d6db9895 (patch)
tree4112505e90ab22936f4de18e15197979dd176cdc
parent249ac1e55c642c670f47aacdc57629bbbf10a8db (diff)
downloadkernel_samsung_aries-01dea1efc23b511d3b58bb94da07ddb6d6db9895.zip
kernel_samsung_aries-01dea1efc23b511d3b58bb94da07ddb6d6db9895.tar.gz
kernel_samsung_aries-01dea1efc23b511d3b58bb94da07ddb6d6db9895.tar.bz2
Btrfs: fix how we set max_size for free space clusters
This patch fixes a problem where max_size can be set to 0 even though we filled the cluster properly. We set max_size to 0 if we restart the cluster window, but if the new start entry is big enough to be our new cluster then we could return with a max_size set to 0, which will mean the next time we try to allocate from this cluster it will fail. So set max_extent to the entry's size. Tested this on my box and now we actually allocate from the cluster after we fill it. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
-rw-r--r--fs/btrfs/free-space-cache.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 5c2caad..cb2849f 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -1296,7 +1296,7 @@ again:
window_start = entry->offset;
window_free = entry->bytes;
last = entry;
- max_extent = 0;
+ max_extent = entry->bytes;
} else {
last = next;
window_free += next->bytes;