mbox series

[v2,0/3] btrfs: adjust overcommit logic and fixes

Message ID cover.1695836511.git.josef@toxicpanda.com (mailing list archive)
Headers show
Series btrfs: adjust overcommit logic and fixes | expand

Message

Josef Bacik Sept. 27, 2023, 5:46 p.m. UTC
Hello,

This is an update to my original patch

https://lore.kernel.org/linux-btrfs/b97e47ce0ce1d41d221878de7d6090b90aa7a597.1695065233.git.josef@toxicpanda.com/

This was causing failures with btrfs/156 and btrfs/177.  The btrfs/156 problem
was caused by the fact that I was just subtracting 1g from the available space.
I missed a spot where we also limit the chunk size to 10% of the file system, so
I've updated the calculation to be exactly what we choose from the chunk
allocator, and this resovled the btrfs/156 failure.

The btrfs/177 failure was actually due to a underflow in ->free_chunk_space
where we weren't adding the new space we got from btrfs_grow_device.  I also
noticed a slight issue with how we remove space from ->free_chunk_space in
btrfs_srhink_device so I fixed that as well.

With these 3 patches we're no longer seeing the above failures and the original
test case is also fixed.  Thanks,

Josef

Josef Bacik (3):
  btrfs: fix ->free_chunk_space math in btrfs_shrink_device
  btrfs: increase ->free_chunk_space in btrfs_grow_device
  btrfs: adjust overcommit logic when very close to full

 fs/btrfs/space-info.c | 32 ++++++++++++++++++++++++++++++++
 fs/btrfs/volumes.c    | 21 ++++++++++++++++++---
 2 files changed, 50 insertions(+), 3 deletions(-)

Comments

David Sterba Oct. 2, 2023, 1:09 p.m. UTC | #1
On Wed, Sep 27, 2023 at 01:46:58PM -0400, Josef Bacik wrote:
> Hello,
> 
> This is an update to my original patch
> 
> https://lore.kernel.org/linux-btrfs/b97e47ce0ce1d41d221878de7d6090b90aa7a597.1695065233.git.josef@toxicpanda.com/
> 
> This was causing failures with btrfs/156 and btrfs/177.  The btrfs/156 problem
> was caused by the fact that I was just subtracting 1g from the available space.
> I missed a spot where we also limit the chunk size to 10% of the file system, so
> I've updated the calculation to be exactly what we choose from the chunk
> allocator, and this resovled the btrfs/156 failure.
> 
> The btrfs/177 failure was actually due to a underflow in ->free_chunk_space
> where we weren't adding the new space we got from btrfs_grow_device.  I also
> noticed a slight issue with how we remove space from ->free_chunk_space in
> btrfs_srhink_device so I fixed that as well.
> 
> With these 3 patches we're no longer seeing the above failures and the original
> test case is also fixed.  Thanks,
> 
> Josef
> 
> Josef Bacik (3):
>   btrfs: fix ->free_chunk_space math in btrfs_shrink_device
>   btrfs: increase ->free_chunk_space in btrfs_grow_device
>   btrfs: adjust overcommit logic when very close to full

Added to misc-next, thanks.