ltp.lists.linux.it archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Petr Vorel <pvorel@suse.cz>, "Darrick J. Wong" <djwong@kernel.org>
Cc: automated-testing@yoctoproject.org,
	Eric Sandeen <sandeen@sandeen.net>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Joerg Vehlow <joerg.vehlow@aox-tech.de>,
	Richard Palethorpe <rpalethorpe@suse.com>,
	LTP List <ltp@lists.linux.it>,
	automated-testing@lists.yoctoproject.org
Subject: Re: [LTP] [RFC PATCH 1/1] API: Allow to use xfs filesystems < 300 MB
Date: Thu, 18 Aug 2022 08:08:35 +0300	[thread overview]
Message-ID: <CAOQ4uxjMEHYQwO25dhs5WtzbOkJcee0HofQDTT3cD-qXJn7xQw@mail.gmail.com> (raw)
In-Reply-To: <Yv2A9Ggkv/NBrTd4@magnolia>

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.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2022-08-18  5:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 20:40 [LTP] [RFC PATCH 1/1] API: Allow to use xfs filesystems < 300 MB Petr Vorel
2022-08-17 23:59 ` Darrick J. Wong
2022-08-18  5:08   ` Amir Goldstein [this message]
2022-08-18  9:45     ` Petr Vorel
2022-08-18  9:01   ` Petr Vorel
2022-08-18  9:53 ` Cyril Hrubis
2022-08-18 11:12   ` Petr Vorel
2022-08-18 11:30     ` Cyril Hrubis
2022-08-18 11:55       ` [LTP] [Automated-testing] " Geert Uytterhoeven
2022-08-19 19:28         ` Petr Vorel
2022-08-20  2:37           ` Li Wang
2022-08-22  9:36             ` Petr Vorel
2022-08-20  2:52   ` [LTP] " Li Wang
2022-08-24 10:21 ` Petr Vorel
2022-08-29  1:45   ` Li Wang
2024-04-03 14:24     ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOQ4uxjMEHYQwO25dhs5WtzbOkJcee0HofQDTT3cD-qXJn7xQw@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=automated-testing@lists.yoctoproject.org \
    --cc=automated-testing@yoctoproject.org \
    --cc=djwong@kernel.org \
    --cc=joerg.vehlow@aox-tech.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    --cc=rpalethorpe@suse.com \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).