summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlexandre Oliva <oliva@lsd.ic.unicamp.br>2011-11-30 22:43:00 +0400
committerChris Mason <chris.mason@oracle.com>2011-11-30 22:43:00 +0400
commitb78d09bceb524ee6481c21b77bda22d766b10e6a (patch)
tree945f0f759dc1c32e091edfe1432f383153d76d19
parentf2d0f6765d6332f9be732965a0c6f3b8a55082b4 (diff)
downloadlinux-b78d09bceb524ee6481c21b77bda22d766b10e6a.tar.xz
Btrfs: reset cluster's max_size when creating bitmap
The field that indicates the size of the largest contiguous chunk of free space in the cluster is not initialized when setting up bitmaps, it's only increased when we find a larger contiguous chunk. We end up retaining a larger value than appropriate for highly-fragmented clusters, which may cause pointless searches for large contiguous groups, and even cause clusters that do not meet the density requirements to be set up. Signed-off-by: Alexandre Oliva <oliva@lsd.ic.unicamp.br> Signed-off-by: Chris Mason <chris.mason@oracle.com>
-rw-r--r--fs/btrfs/free-space-cache.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index ff179b1e7423..ec23d43d0c35 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2320,6 +2320,7 @@ again:
if (!found) {
start = i;
+ cluster->max_size = 0;
found = true;
}