diff options
| author | Josef Bacik | 2015-09-23 20:54:14 +0200 |
|---|---|---|
| committer | Chris Mason | 2015-10-22 03:51:43 +0200 |
| commit | d0bd456074dca089579818312da7cbe726ad2ff9 (patch) | |
| tree | 6dcb3498d7b964a19562dccf8322483359ede3ef /fs/btrfs/free-space-cache.c | |
| parent | Btrfs: fix qgroup sanity tests (diff) | |
| download | kernel-qcow2-linux-d0bd456074dca089579818312da7cbe726ad2ff9.tar.gz kernel-qcow2-linux-d0bd456074dca089579818312da7cbe726ad2ff9.tar.xz kernel-qcow2-linux-d0bd456074dca089579818312da7cbe726ad2ff9.zip | |
Btrfs: add fragment=* debug mount option
In tracking down these weird bitmap problems it was helpful to artificially
create an extremely fragmented file system. These mount options let us either
fragment data or metadata or both. With these options I could reproduce all
sorts of weird latencies and hangs that occur under extreme fragmentation and
get them fixed. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'fs/btrfs/free-space-cache.c')
| -rw-r--r-- | fs/btrfs/free-space-cache.c | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index 5a9431dda07f..c0eb84ecb78f 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -1951,12 +1951,19 @@ static bool use_bitmap(struct btrfs_free_space_ctl *ctl, struct btrfs_free_space *info) { struct btrfs_block_group_cache *block_group = ctl->private; + bool forced = false; + +#ifdef CONFIG_BTRFS_DEBUG + if (btrfs_should_fragment_free_space(block_group->fs_info->extent_root, + block_group)) + forced = true; +#endif /* * If we are below the extents threshold then we can add this as an * extent, and don't have to deal with the bitmap */ - if (ctl->free_extents < ctl->extents_thresh) { + if (!forced && ctl->free_extents < ctl->extents_thresh) { /* * If this block group has some small extents we don't want to * use up all of our free slots in the cache with them, we want |