[LTP] [RFC PATCH 1/1] API: Allow to use xfs filesystems < 300 MB

Amir Goldstein amir73il@gmail.com
Thu Aug 18 07:08:35 CEST 2022


On Thu, Aug 18, 2022 at 2:59 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Wed, Aug 17, 2022 at 10:40:15PM +0200, Petr Vorel wrote:
> > mkfs.xfs since v5.19.0-rc1 [1] refuses to create filesystems < 300 MB.
> > Reuse workaround intended for fstests: set 3 environment variables:
> > export TEST_DIR=1 TEST_DEV=1 QA_CHECK_FS=1
> >
> > Workaround added to both C API (for .needs_device) and shell API (for
> > TST_NEEDS_DEVICE=1).
> >
> > Fix includes any use of filesystem (C API: .all_filesystems,
> > .format_device, shell API: TST_MOUNT_DEVICE=1, TST_FORMAT_DEVICE=1).
> >
> > Fixes various C and shell API failures, e.g.:
> >
> > ./mkfs01.sh -f xfs
> > mkfs01 1 TINFO: timeout per run is 0h 5m 0s
> > tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
> > mkfs01 1 TFAIL: 'mkfs -t xfs  -f /dev/loop0 ' failed.
> > Filesystem must be larger than 300MB.
> >
> > ./creat09
> > ...
> > tst_test.c:1599: TINFO: Testing on xfs
> > tst_test.c:1064: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
> > Filesystem must be larger than 300MB.
> >
> > Link: https://lore.kernel.org/all/164738662491.3191861.15611882856331908607.stgit@magnolia/
> >
> > Reported-by: Martin Doucha <mdoucha@suse.cz>
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Dave, please next time remember there are other testsuites testing XFS,
>
> Dave?? <cough>
>

TBH, it is not about remembering, it is about running integration tests
that catch these test bugs.

Obviously, xfsprogs maintainer (Eric) is running fstests before an
xfsprogs release, but I cannot blame Eric for not running the entire
LTS test suite for xfsprogs release...

I suppose that the bots running LTP on rc kernels might want
to consider also running LTP with rc xfsprogs/e2fsprogs/...
otherwise, those bugs would be caught when *progs hits a distro
that is used to run LTP.

> > not just fstests :). How long do you plan to keep this workaround?
>
> Forever.  In the ideal world we'll some day get around to restructuring
> all the xfstests that do tricky things with sub-500M filesystems, but
> that's the unfortunate part of removing support for small disks.
>

If it's forever, then it should probably have been a command line option.
IIUC, the motivation was to discourage users from formatting too small
filesystems, but if users have a way to do it, they will find it anyway.

Petr,

Notice that the fstests hack was needed for fstests that require MAX fs size,
while the existing LTP lib and tests only have MIN dev size requirement.

> Most of the fstests don't care about the fs size and so they'll run with
> the configured storage (some tens or millions of gigabytes) so we're
> mostly using the same fs sizes that users are expected to have.
>
> > LTP community: do we want to depend on this behavior or we just increase from 256MB to 301 MB
> > (either for XFS or for all). It might not be a good idea to test size users are required
> > to use.
>

For most LTS tests, all you need to do is increase the default (DEV_MIN_SIZE)
from 300MB to 301MB so that's not worth doing any workarounds.

For the 3 memcontrol tests that require dev_min_size = 256 and run on
all_filesystems, it does not look like changing min size is needed at all.

For squashfs01 the xfs limitation is irrelevant, but generally,
If the test min requirement (1MB) is smaller than the lib default,
DEV_MIN_SIZE still meets the test requirement, so why bother
going below the lib default DEV_MIN_SIZE?

Thanks,
Amir.


More information about the ltp mailing list