summaryrefslogtreecommitdiffstats
path: root/fs/btrfs
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-10-07 17:55:34 +0200
committerJosef Bacik <josef@redhat.com>2011-10-19 21:12:55 +0200
commit4b91c14f913f649d4302b3677b85c4ce87a3d8e7 (patch)
tree3c0c0ce1655985e05ab66440c1b9db7890c3a52a /fs/btrfs
parentBtrfs: inline checksums into the disk free space cache (diff)
downloadlinux-4b91c14f913f649d4302b3677b85c4ce87a3d8e7.tar.xz
linux-4b91c14f913f649d4302b3677b85c4ce87a3d8e7.zip
Btrfs: wait for ordered extents if we didn't reclaim enough
I noticed recently that my overcommit patch was causing one of my enospc tests to fail 25% of the time with early ENOSPC. This is because my overcommit patch was letting us go way over board, but it wasn't waiting long enough to let the delalloc shrinker do it's job. The problem is we just start writeback and wait a little bit hoping we flush enough, but we only free up delalloc space by having the writes complete all the way. We do this by waiting for ordered extents, which we do but only if we already free'd enough for the reservation, which isn't right, we should flush ordered extents if we didn't reclaim enough in case that will push us over the edge. With this patch I've not seen a failure in this enospc test after running it in a loop for an hour. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'fs/btrfs')
-rw-r--r--fs/btrfs/extent-tree.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 0abf70c984e9..fc0de6880045 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3406,7 +3406,7 @@ static int shrink_delalloc(struct btrfs_trans_handle *trans,
}
}
- if (reclaimed >= to_reclaim && !trans)
+ if (reclaimed < to_reclaim && !trans)
btrfs_wait_ordered_extents(root, 0, 0);
return reclaimed >= to_reclaim;
}