summaryrefslogtreecommitdiff
path: root/fs
diff options
context:
space:
mode:
authorAlexandre Oliva <oliva@lsd.ic.unicamp.br>2011-11-30 18:43:00 (GMT)
committerChris Mason <chris.mason@oracle.com>2011-11-30 18:43:00 (GMT)
commitb78d09bceb524ee6481c21b77bda22d766b10e6a (patch)
tree945f0f759dc1c32e091edfe1432f383153d76d19 /fs
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>
Diffstat (limited to 'fs')
-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 ff179b1..ec23d43 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;
}