> On Thu, Aug 18, 2022 at 2:59 AM Darrick J. Wong <djwong@xxxxxxxxxx> 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@xxxxxxx> > > > Signed-off-by: Petr Vorel <pvorel@xxxxxxx> > > > --- > > > 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. You're right, that's the only reliable thing. > 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... Not expecting that. > I suppose that the bots running LTP on rc kernels might want > to consider also running LTP with rc xfsprogs/e2fsprogs/... That would be great, but don't expect it'd happen. > otherwise, those bugs would be caught when *progs hits a distro > that is used to run LTP. That's what happen on openSUSE. > > > 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. +1 > 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. FYI DEV_MIN_SIZE is used just for tests which test LTP API itself. For real tests is DEV_SIZE_MB (lib/tst_device.c). And actually 300 MB is enough, therefore the only change for the default values is: DEV_SIZE_MB from 256 to 300 (should be enough for all LTP tests: C and shell API, also these tests of LTP API itself). I also think 46MB is not worth of hacks. BTW for some reason DEV_MIN_SIZE was higher than the default (probably to test library with non-default value, but now is the same, we might want to increase it (or remove it). > 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. Indeed, this value can stay. This check is here because although LTP uses loop device by default, any device can be used via LTP_DEV env variable. > 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? For use with LTP_DEV. Anyway, Darrick, Amir, thank you both for your input. Kind regards, Petr > Thanks, > Amir.
