forked from Minki/linux
Btrfs: don't continue setting up space cache when enospc
If we hit ENOSPC when setting up a space cache don't bother setting up any of the other space cache's in this transaction, it'll just induce unnecessary latency. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com>
This commit is contained in:
parent
4f4db2174d
commit
2968b1f48b
@ -3402,6 +3402,15 @@ again:
|
||||
}
|
||||
spin_unlock(&block_group->lock);
|
||||
|
||||
/*
|
||||
* We hit an ENOSPC when setting up the cache in this transaction, just
|
||||
* skip doing the setup, we've already cleared the cache so we're safe.
|
||||
*/
|
||||
if (test_bit(BTRFS_TRANS_CACHE_ENOSPC, &trans->transaction->flags)) {
|
||||
ret = -ENOSPC;
|
||||
goto out_put;
|
||||
}
|
||||
|
||||
/*
|
||||
* Try to preallocate enough space based on how big the block group is.
|
||||
* Keep in mind this has to include any pinned space which could end up
|
||||
@ -3422,8 +3431,18 @@ again:
|
||||
ret = btrfs_prealloc_file_range_trans(inode, trans, 0, 0, num_pages,
|
||||
num_pages, num_pages,
|
||||
&alloc_hint);
|
||||
/*
|
||||
* Our cache requires contiguous chunks so that we don't modify a bunch
|
||||
* of metadata or split extents when writing the cache out, which means
|
||||
* we can enospc if we are heavily fragmented in addition to just normal
|
||||
* out of space conditions. So if we hit this just skip setting up any
|
||||
* other block groups for this transaction, maybe we'll unpin enough
|
||||
* space the next time around.
|
||||
*/
|
||||
if (!ret)
|
||||
dcs = BTRFS_DC_SETUP;
|
||||
else if (ret == -ENOSPC)
|
||||
set_bit(BTRFS_TRANS_CACHE_ENOSPC, &trans->transaction->flags);
|
||||
btrfs_free_reserved_data_space(inode, num_pages);
|
||||
|
||||
out_put:
|
||||
|
@ -34,6 +34,7 @@ enum btrfs_trans_state {
|
||||
|
||||
#define BTRFS_TRANS_HAVE_FREE_BGS 0
|
||||
#define BTRFS_TRANS_DIRTY_BG_RUN 1
|
||||
#define BTRFS_TRANS_CACHE_ENOSPC 2
|
||||
|
||||
struct btrfs_transaction {
|
||||
u64 transid;
|
||||
|
Loading…
Reference in New Issue
Block a user