[packages/kernel/LINUX_5_4] Revert "Add xfs fix for reservation blocks that wasn't backported to stable kernels."

[baggins]

commit 4b362f5fa457c9bf0ded9a7541bf68fdef01dbe2
Author: Jan Rękorajski <baggins at pld-linux.org>
Date:   Tue Mar 8 23:24:08 2022 +0100

    Revert "Add xfs fix for reservation blocks that wasn't backported to stable kernels."
    
    This reverts commit 6fc3f9fc2e7812e19e44e4ccc3d27b627fa48422.
    
    fs/xfs/xfs_mount.c:1272:64: error: 'struct xfs_mount' has no member named 'm_allocbt_blks'

 kernel-small_fixes.patch | 85 ------------------------------------------------
 1 file changed, 85 deletions(-)
---
diff --git a/kernel-small_fixes.patch b/kernel-small_fixes.patch
index fe6159f3..a611dd91 100644
--- a/kernel-small_fixes.patch
+++ b/kernel-small_fixes.patch
@@ -530,88 +530,3 @@ diff -ur linux-5.3/drivers/scsi/aacraid.org/linit.c linux-5.3/drivers/scsi/aacra
  		aac_define_int_mode(dev);
  
  	if (dev->msi_enabled)
-commit fd43cf600cf61c66ae0a1021aca2f636115c7fcb
-Author: Brian Foster <bfoster at redhat.com>
-Date:   Wed Apr 28 15:06:05 2021 -0700
-
-    xfs: set aside allocation btree blocks from block reservation
-    
-    The blocks used for allocation btrees (bnobt and countbt) are
-    technically considered free space. This is because as free space is
-    used, allocbt blocks are removed and naturally become available for
-    traditional allocation. However, this means that a significant
-    portion of free space may consist of in-use btree blocks if free
-    space is severely fragmented.
-    
-    On large filesystems with large perag reservations, this can lead to
-    a rare but nasty condition where a significant amount of physical
-    free space is available, but the majority of actual usable blocks
-    consist of in-use allocbt blocks. We have a record of a (~12TB, 32
-    AG) filesystem with multiple AGs in a state with ~2.5GB or so free
-    blocks tracked across ~300 total allocbt blocks, but effectively at
-    100% full because the the free space is entirely consumed by
-    refcountbt perag reservation.
-    
-    Such a large perag reservation is by design on large filesystems.
-    The problem is that because the free space is so fragmented, this AG
-    contributes the 300 or so allocbt blocks to the global counters as
-    free space. If this pattern repeats across enough AGs, the
-    filesystem lands in a state where global block reservation can
-    outrun physical block availability. For example, a streaming
-    buffered write on the affected filesystem continues to allow delayed
-    allocation beyond the point where writeback starts to fail due to
-    physical block allocation failures. The expected behavior is for the
-    delalloc block reservation to fail gracefully with -ENOSPC before
-    physical block allocation failure is a possibility.
-    
-    To address this problem, set aside in-use allocbt blocks at
-    reservation time and thus ensure they cannot be reserved until truly
-    available for physical allocation. This allows alloc btree metadata
-    to continue to reside in free space, but dynamically adjusts
-    reservation availability based on internal state. Note that the
-    logic requires that the allocbt counter is fully populated at
-    reservation time before it is fully effective. We currently rely on
-    the mount time AGF scan in the perag reservation initialization code
-    for this dependency on filesystems where it's most important (i.e.
-    with active perag reservations).
-    
-    Signed-off-by: Brian Foster <bfoster at redhat.com>
-    Reviewed-by: Chandan Babu R <chandanrlinux at gmail.com>
-    Reviewed-by: Allison Henderson <allison.henderson at oracle.com>
-    Reviewed-by: Darrick J. Wong <djwong at kernel.org>
-    Signed-off-by: Darrick J. Wong <djwong at kernel.org>
-
-diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
-index cb1e2c4702c3..bdfee1943796 100644
---- a/fs/xfs/xfs_mount.c
-+++ b/fs/xfs/xfs_mount.c
-@@ -1188,6 +1188,7 @@ xfs_mod_fdblocks(
- 	int64_t			lcounter;
- 	long long		res_used;
- 	s32			batch;
-+	uint64_t		set_aside;
- 
- 	if (delta > 0) {
- 		/*
-@@ -1227,8 +1228,20 @@ xfs_mod_fdblocks(
- 	else
- 		batch = XFS_FDBLOCKS_BATCH;
- 
-+	/*
-+	 * Set aside allocbt blocks because these blocks are tracked as free
-+	 * space but not available for allocation. Technically this means that a
-+	 * single reservation cannot consume all remaining free space, but the
-+	 * ratio of allocbt blocks to usable free blocks should be rather small.
-+	 * The tradeoff without this is that filesystems that maintain high
-+	 * perag block reservations can over reserve physical block availability
-+	 * and fail physical allocation, which leads to much more serious
-+	 * problems (i.e. transaction abort, pagecache discards, etc.) than
-+	 * slightly premature -ENOSPC.
-+	 */
-+	set_aside = mp->m_alloc_set_aside + atomic64_read(&mp->m_allocbt_blks);
- 	percpu_counter_add_batch(&mp->m_fdblocks, delta, batch);
--	if (__percpu_counter_compare(&mp->m_fdblocks, mp->m_alloc_set_aside,
-+	if (__percpu_counter_compare(&mp->m_fdblocks, set_aside,
- 				     XFS_FDBLOCKS_BATCH) >= 0) {
- 		/* we had space! */
- 		return 0;
================================================================

---- gitweb:

http://git.pld-linux.org/gitweb.cgi/packages/kernel.git/commitdiff/2a3ffedc688af42210211a9fd1bb893c72867dac