diff options
| author | Josef Bacik <josef@redhat.com> | 2011-05-11 17:30:53 -0400 |
|---|---|---|
| committer | Josef Bacik <josef@redhat.com> | 2011-05-23 13:03:13 -0400 |
| commit | 589d8ade83f07c0f11c8191c0ca309f34d7a2c14 (patch) | |
| tree | e1e628bd721ae6fd34e1454f8124ecb9a2b3464f /fs | |
| parent | d82a6f1d7e8b61ed5996334d0db66651bb43641d (diff) | |
| download | linux-3.10-589d8ade83f07c0f11c8191c0ca309f34d7a2c14.tar.gz linux-3.10-589d8ade83f07c0f11c8191c0ca309f34d7a2c14.tar.bz2 linux-3.10-589d8ade83f07c0f11c8191c0ca309f34d7a2c14.zip | |
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>
Diffstat (limited to 'fs')
| -rw-r--r-- | fs/btrfs/extent-tree.c | 19 |
1 files changed, 11 insertions, 8 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 9f0a4e3bd8a..96be6245031 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -378,15 +378,18 @@ again: if (ret) break; - caching_ctl->progress = last; - btrfs_release_path(extent_root, path); - up_read(&fs_info->extent_commit_sem); - mutex_unlock(&caching_ctl->mutex); - if (btrfs_transaction_in_commit(fs_info)) - schedule_timeout(1); - else + if (need_resched() || + btrfs_next_leaf(extent_root, path)) { + caching_ctl->progress = last; + btrfs_release_path(extent_root, path); + up_read(&fs_info->extent_commit_sem); + mutex_unlock(&caching_ctl->mutex); cond_resched(); - goto again; + goto again; + } + leaf = path->nodes[0]; + nritems = btrfs_header_nritems(leaf); + continue; } if (key.objectid < block_group->key.objectid) { |