All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: stable@vger.kernel.org, Marc Lehmann <schmorp@schmorp.de>,
	Josef Bacik <josef@toxicpanda.com>
Subject: [PATCH 9 11/12] btrfs: space-info: Use per-profile available space in can_overcommit()
Date: Thu,  1 Oct 2020 13:57:43 +0800	[thread overview]
Message-ID: <20201001055744.103261-12-wqu@suse.com> (raw)
In-Reply-To: <20201001055744.103261-1-wqu@suse.com>

For the following disk layout, can_overcommit() can cause false
confidence in available space:

  devid 1 unallocated:	1T
  devid 2 unallocated:	10T
  metadata type:	RAID1

As can_overcommit() simply uses unallocated space with factor to
calculate the allocatable metadata chunk size.

can_overcommit() believes we still have 5.5T for metadata chunks, while
the truth is, we only have 1T available for metadata chunks.
This can lead to ENOSPC at run_delalloc_range() and cause transaction
abort.

Since factor based calculation can't distinguish RAID1/RAID10 and DUP at
all, we need proper chunk-allocator level awareness to do such estimation.

Thankfully, we have per-profile available space already calculated, just
use that facility to avoid such false confidence.

CC: stable@vger.kernel.org # 5.4+
Reported-by: Marc Lehmann <schmorp@schmorp.de>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/space-info.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
index 64b6e1d44f47..4bb4e3c3531f 100644
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@ -336,25 +336,21 @@ static u64 calc_available_free_space(struct btrfs_fs_info *fs_info,
 			  struct btrfs_space_info *space_info,
 			  enum btrfs_reserve_flush_enum flush)
 {
+	enum btrfs_raid_types index;
 	u64 profile;
 	u64 avail;
-	int factor;
 
 	if (space_info->flags & BTRFS_BLOCK_GROUP_SYSTEM)
 		profile = btrfs_system_alloc_profile(fs_info);
 	else
 		profile = btrfs_metadata_alloc_profile(fs_info);
 
-	avail = atomic64_read(&fs_info->free_chunk_space);
-
 	/*
-	 * If we have dup, raid1 or raid10 then only half of the free
-	 * space is actually usable.  For raid56, the space info used
-	 * doesn't include the parity drive, so we don't have to
-	 * change the math
+	 * Grab avail space from per-profile array which should be as accurate
+	 * as chunk allocator.
 	 */
-	factor = btrfs_bg_type_to_factor(profile);
-	avail = div_u64(avail, factor);
+	index = btrfs_bg_flags_to_raid_index(profile);
+	avail = atomic64_read(&fs_info->fs_devices->per_profile_avail[index]);
 
 	/*
 	 * If we aren't flushing all things, let us overcommit up to
-- 
2.28.0


  parent reply	other threads:[~2020-10-01  5:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  5:57 [PATCH 9 00/12] Introduce per-profile available space array to avoid over-confident can_overcommit() Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 01/12] btrfs: block-group: cleanup btrfs_add_block_group_cache() Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 02/12] btrfs: block-group: extra the code to delete block group from fs_info rb tree Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 03/12] btrfs: block-group: make link_block_group() to handle avail alloc bits Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 04/12] btrfs: block-group: extract the code to unlink block group from space info Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 05/12] btrfs: space-info: update btrfs_update_space_info() to handle block group removal Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 06/12] btrfs: block-group: introduce btrfs_revert_block_group() Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 07/12] btrfs: volumes: introduce the device layout aware per-profile available space infrastructure Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 08/12] btrfs: volumes: update per-profile available space at mount time Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 09/12] btrfs: volumes: call btrfs_update_per_profile_avail() for chunk allocation and removal Qu Wenruo
2020-10-01  5:57 ` [PATCH 9 10/12] btrfs: volumes: update per-profile available space for device update Qu Wenruo
2020-10-01  5:57 ` Qu Wenruo [this message]
2020-10-01  5:57 ` [PATCH 9 12/12] btrfs: statfs: Use pre-calculated per-profile available space Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201001055744.103261-12-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=schmorp@schmorp.de \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.