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:
> > In order to detect whether the current kernel supports XFS shrinking.
> >
> > Signed-off-by: Gao Xiang <hsiangkao@xxxxxxxxxx>
> > ---
> > 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
>
> > + _scratch_unmount
> > +}
> > +
> > # XFS ability to change UUIDs on V5/CRC filesystems
> > #
> > _require_meta_uuid()
> > --
> > 2.27.0
> >
>
