]> git.apps.os.sepia.ceph.com Git - xfsprogs-dev.git/commit
xfs: fix unit conversion error in xfs_log_calc_max_attrsetm_res
authorDarrick J. Wong <djwong@kernel.org>
Mon, 29 Jul 2024 23:22:50 +0000 (16:22 -0700)
committerDarrick J. Wong <djwong@kernel.org>
Tue, 30 Jul 2024 00:01:03 +0000 (17:01 -0700)
commit86bd3beb96ae89f5e047b48213f202680db92fea
treea0f9d938a2ac27f5cd1b74f324f0b07fd15ada1b
parent89a6faedb0ec26fb71279ac37cf7c8147174ce58
xfs: fix unit conversion error in xfs_log_calc_max_attrsetm_res

Source kernel commit: 7ea816ca4043c2bc6052f696b6aebe2c22980a03

Dave and I were discussing some recent test regressions as a result of
me turning on nrext64=1 on realtime filesystems, when we noticed that
the minimum log size of a 32M filesystem jumped from 954 blocks to 4287
blocks.

Digging through xfs_log_calc_max_attrsetm_res, Dave noticed that @size
contains the maximum estimated amount of space needed for a local format
xattr, in bytes, but we feed this quantity to XFS_NEXTENTADD_SPACE_RES,
which requires units of blocks.  This has resulted in an overestimation
of the minimum log size over the years.

We should nominally correct this, but there's a backwards compatibility
problem -- if we enable it now, the minimum log size will decrease.  If
a corrected mkfs formats a filesystem with this new smaller log size, a
user will encounter mount failures on an uncorrected kernel due to the
larger minimum log size computations there.

Therefore, turn this on for parent pointers because it wasn't merged at
all upstream when this issue was discovered.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
libxfs/xfs_log_rlimit.c