summaryrefslogtreecommitdiff
path: root/fs/btrfs/extent-tree.c
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-05-13 10:32:11 -0400
committerJosef Bacik <josef@redhat.com>2011-05-23 13:03:14 -0400
commit026fd317828500524cdc7e5ff9e8e7923abb2868 (patch)
treed303bffbd895c307f49286cd90186cf58223dde2 /fs/btrfs/extent-tree.c
parent589d8ade83f07c0f11c8191c0ca309f34d7a2c14 (diff)
Btrfs: don't always do readahead
Our readahead is sort of sloppy, and really isn't always needed. For example if ls is doing a stating ls (which is the default) it's going to stat in non-disk order, so if say you have a directory with a stupid amount of files, readahead is going to do nothing but waste time in the case of doing the stat. Taking the unconditional readahead out made my test go from 57 minutes to 36 minutes. This means that everywhere we do loop through the tree we want to make sure we do set path->reada properly, so I went through and found all of the places where we loop through the path and set reada to 1. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'fs/btrfs/extent-tree.c')
-rw-r--r--fs/btrfs/extent-tree.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 96be62450318..1ba2cc58eab5 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -347,7 +347,7 @@ static int caching_kthread(void *data)
*/
path->skip_locking = 1;
path->search_commit_root = 1;
- path->reada = 2;
+ path->reada = 1;
key.objectid = last;
key.offset = 0;
@@ -8556,6 +8556,7 @@ int btrfs_read_block_groups(struct btrfs_root *root)
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
+ path->reada = 1;
cache_gen = btrfs_super_cache_generation(&root->fs_info->super_copy);
if (cache_gen != 0 &&