[PATCH v2 0/3] btrfs: unbalanced disks aware per-profile available space estimation

[Qu Wenruo <wqu@suse.com>]

[CHANGELOG]
v2:
- Various grammar fixes

- Fix a u64 division compiling error on ppc64
  Which requires the dedicated div_u64() helper.

- Ignore unallocated space that's too small
  If the unallocated space is not enough to even cover a single stripe
  (64K), don't utilize it.
  This makes the behavior more aligned to the chunk allocator, and
  prevent over-estimation.

- Use U64_MAX to mark the per-profile estimation as unavailable
  This reduce the memory usage by one unsigned long.

- Update the commit message of the 2nd patch
  To include the overhead (runtime of btrfs_update_per_profile_avail())
  in the commit message.

- Minor comment cleanup on the term "balloon"
  The old term "balloon" is no longer utilized and there is a typo.
  ("ballon" -> "balloon").

- Update the estimation examples in the first patch
  As we allows 2 disks raid5 and 3 disks raid6.

v1:
- Revive from the v5.9 era fix

- Make btrfs_update_per_profile_avail() to not return error
  Instead just mark all profiles as unavailable, and
  btrfs_get_per_profile_avail() will return false.

  The caller will need to fallback to the existing factor based
  estimation.

  This greatly simplified the error handling, which is a pain point in
  the original series.

- Remove a lot of refactor/cleanup
  As that's already done in upstream.

- Only make calc_available_free_space() to use the new infrastructure
  That's the main goal, fix can_over_commit().
  Further enhancement can be done later.

There is a long known bug that if metadata is using RAID1 on two
unbalanced disks, btrfs have a very high chance to hit -ENOSPC during
critical paths and flips RO.

The bug dates back to v5.9 (where my last updates ends) and the most
recent bug report is from Christoph.

The idea to fix it is always here, by providing a chunk-allocator-like
available space estimation.
It doesn't need to be as heavy as chunk allocator, but at least it
should not over-estimate.

The demon is always in the details, the previous v5.9 era series
requires a lot of changes in error handling, because the
btrfs_update_per_profile_avail() can fail at critical paths in chunk
allocation/removal and device grow/shrink/add/removal.

But this time that function will no longer fail, but just mark
per-profile available estimation as unreliable, and let the caller to
fallback to the old factor based solution.

In the real world it should not be a big deal, as the only error is
-ENOMEM, but this greatly simplifies the error handling.

Qu Wenruo (3):
  btrfs: introduce the device layout aware per-profile available space
  btrfs: update per-profile available estimation
  btrfs: use per-profile available space in calc_available_free_space()

 fs/btrfs/space-info.c |  27 ++++---
 fs/btrfs/volumes.c    | 183 +++++++++++++++++++++++++++++++++++++++++-
 fs/btrfs/volumes.h    |  34 ++++++++
 3 files changed, 231 insertions(+), 13 deletions(-)

-- 
2.52.0