On Mon, May 10, 2021 at 10:59:52AM -0700, Darrick J. Wong wrote:

On Fri, Apr 02, 2021 at 05:49:35PM +0800, Gao Xiang wrote:

quoted

In order to detect whether the current kernel supports XFS shrinking.

Signed-off-by: Gao Xiang <redacted>
---
 common/xfs | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/common/xfs b/common/xfs
index 69f76d6e..c6c2e3f5 100644
--- a/common/xfs
+++ b/common/xfs

@@ -766,6 +766,20 @@ _require_xfs_mkfs_without_validation()
 	fi
 }
 
+_require_xfs_scratch_shrink()
+{
+	_require_scratch
+	_require_command "$XFS_GROWFS_PROG" xfs_growfs
+
+	_scratch_mkfs_xfs | _filter_mkfs 2>$tmp.mkfs >/dev/null
+	. $tmp.mkfs
+	_scratch_mount
+	# here just to check if kernel supports, no need do more extra work
+	$XFS_GROWFS_PROG -D$((dblocks-1)) "$SCRATCH_MNT" > /dev/null 2>&1 || \
+		_notrun "kernel does not support shrinking"

I think isn't sufficiently precise -- if xfs_growfs (userspace) doesn't
support shrinking it'll error out with "data size XXX too small", and if
the kernel doesn't support shrink, it'll return EINVAL.

I'm not sure if we need to identify such 2 cases (xfsprogs doesn't support
and/or kernel doesn't support), but if it's really needed I think I could
update it. But I've confirmed with testing that both two cases can be
handled with the statements above properly.

As written, this code attempts a single-block shrink and disables the
entire test if that fails for any reason, even if that reason is that
the last block in the filesystem isn't free, or we ran out of memory, or
something like that.

hmm... the filesystem here is brandly new, I think at least it'd be
considered as "the last block in the new filesystem is free". If we're
worried that such promise could be broken, I think some other golden
output is unstable as well (although unrelated to this.) By that time,
I think the test script should be updated then instead. Or am I missing
something?

If we're worried about runing out of memory, I think the whole xfstests
could not be predictable. I'm not sure if we need to handle such case.

I think this needs to check the output of xfs_growfs to make the
decision to _notrun.

I could check some golden output such as "data size XXX too small", yet
I still don't think we should check some cases e.g. run out of memory..

Thanks,
Gao Xiang

--D

quoted

+	_scratch_unmount
+}
+
 # XFS ability to change UUIDs on V5/CRC filesystems
 #
 _require_meta_uuid()
-- 
2.27.0