aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-05-11 17:30:53 -0400
committerJosef Bacik <josef@redhat.com>2011-05-23 13:03:13 -0400
commit589d8ade83f07c0f11c8191c0ca309f34d7a2c14 (patch)
treee1e628bd721ae6fd34e1454f8124ecb9a2b3464f
parentd82a6f1d7e8b61ed5996334d0db66651bb43641d (diff)
Btrfs: try not to sleep as much when doing slow caching
When the fs is super full and we unmount the fs, we could get stuck in this thing where unmount is waiting for the caching kthread to make progress and the caching kthread keeps scheduling because we're in the middle of a commit. So instead just let the caching kthread keep going and only yeild if need_resched(). This makes my horrible umount case go from taking up to 10 minutes to taking less than 20 seconds. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com>
-rw-r--r--fs/btrfs/extent-tree.c19
1 files changed, 11 insertions, 8 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 9f0a4e3bd8a9..96be62450318 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -378,15 +378,18 @@ again:
378 if (ret) 378 if (ret)
379 break; 379 break;
380 380
381 caching_ctl->progress = last; 381 if (need_resched() ||
382 btrfs_release_path(extent_root, path); 382 btrfs_next_leaf(extent_root, path)) {
383 up_read(&fs_info->extent_commit_sem); 383 caching_ctl->progress = last;
384 mutex_unlock(&caching_ctl->mutex); 384 btrfs_release_path(extent_root, path);
385 if (btrfs_transaction_in_commit(fs_info)) 385 up_read(&fs_info->extent_commit_sem);
386 schedule_timeout(1); 386 mutex_unlock(&caching_ctl->mutex);
387 else
388 cond_resched(); 387 cond_resched();
389 goto again; 388 goto again;
389 }
390 leaf = path->nodes[0];
391 nritems = btrfs_header_nritems(leaf);
392 continue;
390 } 393 }
391 394
392 if (key.objectid < block_group->key.objectid) { 395 if (key.objectid < block_group->key.objectid) {