diff options
| author | Josef Bacik <josef@redhat.com> | 2012-04-13 00:03:57 +0400 |
|---|---|---|
| committer | Chris Mason <chris.mason@oracle.com> | 2012-04-13 04:54:01 +0400 |
| commit | d53ba47484ed6245e640ee4bfe9d21e9bfc15765 (patch) | |
| tree | 12bcb989f0e210f25770a72441eb8b947fd2fad3 /fs/btrfs/extent-tree.c | |
| parent | 4edc2ca388d62abffe38149f6ac00e749ea721c5 (diff) | |
| download | linux-d53ba47484ed6245e640ee4bfe9d21e9bfc15765.tar.xz | |
Btrfs: use commit root when loading free space cache
A user reported that booting his box up with btrfs root on 3.4 was way
slower than on 3.3 because I removed the ideal caching code. It turns out
that we don't load the free space cache if we're in a commit for deadlock
reasons, but since we're reading the cache and it hasn't changed yet we are
safe reading the inode and free space item from the commit root, so do that
and remove all of the deadlock checks so we don't unnecessarily skip loading
the free space cache. The user reported this fixed the slowness. Thanks,
Tested-by: Calvin Walton <calvin.walton@kepstin.ca>
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'fs/btrfs/extent-tree.c')
| -rw-r--r-- | fs/btrfs/extent-tree.c | 4 |
1 files changed, 1 insertions, 3 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index a2134d8141c1..2b35f8d14bb9 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -529,9 +529,7 @@ static int cache_block_group(struct btrfs_block_group_cache *cache, * allocate blocks for the tree root we can't do the fast caching since * we likely hold important locks. */ - if (trans && (!trans->transaction->in_commit) && - (root && root != root->fs_info->tree_root) && - btrfs_test_opt(root, SPACE_CACHE)) { + if (fs_info->mount_opt & BTRFS_MOUNT_SPACE_CACHE) { ret = load_free_space_cache(fs_info, cache); spin_lock(&cache->lock); |