@@ -4277,8 +4277,13 @@ out:
static inline int need_do_async_reclaim(struct btrfs_space_info *space_info,
struct btrfs_fs_info *fs_info, u64 used)
{
- return (used >= div_factor_fine(space_info->total_bytes, 98) &&
- !btrfs_fs_closing(fs_info) &&
+ u64 thresh = div_factor_fine(space_info->total_bytes, 98);
+
+ /* If we're just plain full then async reclaim just slows us down. */
+ if (space_info->bytes_used >= thresh)
+ return 0;
+
+ return (used >= thresh && !btrfs_fs_closing(fs_info) &&
!test_bit(BTRFS_FS_STATE_REMOUNTING, &fs_info->fs_state));
}
@@ -4333,10 +4338,7 @@ static void btrfs_async_reclaim_metadata_space(struct work_struct *work)
if (!btrfs_need_do_async_reclaim(space_info, fs_info,
flush_state))
return;
- } while (flush_state <= COMMIT_TRANS);
-
- if (btrfs_need_do_async_reclaim(space_info, fs_info, flush_state))
- queue_work(system_unbound_wq, work);
+ } while (flush_state < COMMIT_TRANS);
}
void btrfs_init_async_reclaim_work(struct work_struct *work)
We noticed on our gluster boxes that rm's when very full we'd take forever. This was because the async flusher thread was committing the transaction over and over because we had no delalloc, no delayed items and no room to allocate new block groups. So fix a few things 1) Don't commit the transaction. If we need to do it we will do it ourselves. 2) Don't requeue ourselves. Once we stopped committing the transaction we would end up burning a CPU by just requeueing ourselves over and over again because we thought we need to flush more. 3) Don't bother doing async reclaim if we're just full. If we have 98% of our space actually used then doing things async really isn't going to be helpful, so skip it. This patch made the rm's on our extremely full gluster boxes not take all eternity. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> --- fs/btrfs/extent-tree.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)