All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Leah Rumancik <leah.rumancik@gmail.com>,
	lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	Disha Goel <disgoel@linux.ibm.com>
Subject: Re: [LSF/MM/BPF TOPIC] Filesystem testing
Date: Sun, 17 Mar 2024 23:52:36 +0530	[thread overview]
Message-ID: <87h6h4sopf.fsf@doe.com> (raw)
In-Reply-To: <CACzhbgQakTF_ahv9HokgnwpW69q8M103w1kmhBBi21ZTkmRTEA@mail.gmail.com>

Leah Rumancik <leah.rumancik@gmail.com> writes:

> Last year we covered the new process for backporting to XFS. There are
> still remaining pain points: establishing a baseline for new branches
> is time consuming, testing resources aren't easy to come by for
> everyone, and selecting appropriate patches is also time consuming. To
> avoid the need to establish a baseline, I'm planning on converting to
> a model in which I only run failed tests on the baseline. I test with
> gce-xfstests and am hoping to automate a relaunch of failed tests.
> Perhaps putting the logic to process the results and form new ./check
> commands could live in fstests-dev in case it is useful for other
> testing infrastructures.

Nice idea. Another painpoint to add - 
4k blocksize gets tested a lot but as soon as we switch to large block
size testing, either with LBS, or on a system with larger pagesize...
...we quickly starts seeing problems. Most of them could be testcase
failure, so if this could help establish a baseline, that might be helpful.


Also if could collborate on exclude/known failures w.r.t different
test configs that might come handy for people who are looking to help in
this effort. In fact, why not have different filesystems cfg files and their
corresponding exclude files as part of fstests repo itself?  
I know xfstests-bld maintains it here [1][2][3]. And it is rather
very convinient to point this out to anyone who asks me of what test
configs to test with or what tests are considered to be testcase
failures bugs with a given fs config.

So it will very helpful if we could have a mechanism such that all of
this fs configs (and it's correspinding excludes) could be maintained in
fstests itself, and anyone who is looking to test any fs config should
be quickly be able to test it with ./check <fs_cfg_params>. Has this
already been discussed before? Does this sound helpful for people who
are looking to contribute in this effort of fs testing?


[1] [ext4]: https://github.com/tytso/xfstests-bld/tree/master/test-appliance/files/root/fs/ext4/cfg
[2] [xfs]: https://github.com/tytso/xfstests-bld/tree/master/test-appliance/files/root/fs/xfs/cfg
[3] [fs]: https://github.com/tytso/xfstests-bld/tree/master/test-appliance/files/root/fs/

-ritesh

  parent reply	other threads:[~2024-03-17 18:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-14 15:30 [LSF/MM/BPF TOPIC] Filesystem testing Leah Rumancik
2024-03-15 20:32 ` Luis Chamberlain
2024-03-17 18:22 ` Ritesh Harjani [this message]
2024-03-18 18:48   ` Gabriel Krisman Bertazi
2024-03-18 22:06     ` Dave Chinner
2024-04-11 19:24       ` Luis Chamberlain

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=87h6h4sopf.fsf@doe.com \
    --to=ritesh.list@gmail.com \
    --cc=disgoel@linux.ibm.com \
    --cc=leah.rumancik@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=naresh.kamboju@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.