From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 5/5] Add test for data integrity over NFS
Date: Mon, 4 Nov 2024 15:16:06 +0100 [thread overview]
Message-ID: <20241104141606.GB1388681@pevik> (raw)
In-Reply-To: <ZyjGiQ7-oyBZBG-S@yuki.lan>
> Hi!
> > Test timed out, sending SIGTERM!
> > If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1
> > Sending SIGKILL to test process...
> > Test is still running... 10
> > Test is still running... 9
> > Test is still running... 8
> > Test is still running... 7
> > Test is still running... 6
> > Test is still running... 5
> > Test is still running... 4
> > Test is still running... 3
> > Test is still running... 2
> > Test is still running... 1
> > Test is still running, sending SIGKILL
> > Killed
> Isn't the propblem here that the fsplough.c itself does not have
> .max_runtime set?
It has timeout adjusted in the setup function:
tst_set_max_runtime(bufsize * loop_count / (8 * 1024 * 1024));
> I think that main problem here is that we have a LTP test that is being
> executed from another LTP test which means that we have two layers of
> everything including timeouts.
Similarly netstress.c, which is also called from tst_net.sh. But these tests
does not run on all filesystems.
> > The quickest way would be to use the same calculation (* $TST_CNT + 5% for spare
> > time) in nfs10.sh and increase tst_set_timeout with.
> > Or, I wonder if using tst_loader.sh and tst_run_shell.c would help to integrate
> > these. But I'm not sure how easily could be nfs_lib.sh integrated, e.g.
> > * isn't it too late, when it uses tst_net.sh (maybe this file would need to be
> > integrated)
> > * should use keep using TST_ALL_FILESYSTEMS=1 from tst_test.sh or configure
> > via all_filesystems=1 via json?
> I guess that the best solution would be to add NFS support into the
> tst_test.c as another filesystem. That way we would get much more
> coverate than we do now. I guess that it would be doable as long as the
> configuration on how to do that is passed to the test library somehow.
Test coverage would really increase a lot. Even there are more NFS testsuites,
IMHO it'd be useful to bring this to LTP - we test a different things then
fstests, pynfs, cthon, ....
But OTOH it does not have much sense to run NFS tests on a loop device which
backing file is on tmpfs (the default setup on distros which use tmpfs on /tmp).
It's a question, whether we should start using /var/tmp as a default for TMPDIR
(if exists). LTP does cleanup of the functions, unless it fails. Specially NFS
tests when they timeout, the cleanup is not done due mounted filesystem being
used. Then /var/tmp gets filled up quickly and reboot does not do automatic
cleanup.
Adding NFS support would require setup code from nfs_lib.sh (e.g. exportfs, run
mount binary or start using mount(2), doing various checks etc) to be run by
tst_test.c, via another process via fork() and execvp(), e.g. with LTP's
tst_cmd(). I'm not sure if minimal required subset should be put in some shell
script, which would be executed by tst_test.c (maybe using tst_loader.sh to join
shared memory to unify the counter) or run individual commands one by one. WDYT?
This simpler version would allow to add various NFS to all_filesystems. I wonder
if we want to support just single NFS version e.g. the newest NFSv4.2 or more.
I suppose we would test only on TCP (UDP is deprecated, not enabled by default
on newer kernels). But even the core of the NFS setup in nfs_mount() uses
tst_rhost_run() from tst_net.sh. E.g. some parts of tst_net.sh would need to be
rewritten into C code (or it would have to call tst_net.sh, if gluing with
tst_loader.sh would work).
My original idea to convert all NFS tests would basically mean to rewrite quite
to use even more nfs_lib.sh and tst_net.sh. code (there is a support for
setting NFS version and protocol and other things).
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-11-04 14:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-01 14:11 [LTP] [PATCH 0/5] Add LVM and NFS tests for file data integrity Martin Doucha
2024-11-01 14:11 ` [LTP] [PATCH 1/5] Move preadv()/pwritev() backup definitions to LAPI Martin Doucha
2024-11-01 22:40 ` Petr Vorel
2024-11-01 14:11 ` [LTP] [PATCH 2/5] Add safe readv()/writev() functions Martin Doucha
2024-11-01 14:11 ` [LTP] [PATCH 3/5] Add test for file data integrity Martin Doucha
2024-12-04 13:45 ` Cyril Hrubis
2024-12-04 14:39 ` Martin Doucha
2024-11-01 14:11 ` [LTP] [PATCH 4/5] Add support for setting loop device size in shell tests Martin Doucha
2024-11-01 22:45 ` Petr Vorel
2024-11-28 8:19 ` Petr Vorel
2024-11-01 14:11 ` [LTP] [PATCH 5/5] Add test for data integrity over NFS Martin Doucha
2024-11-01 23:32 ` Petr Vorel
2024-11-04 13:05 ` Cyril Hrubis
2024-11-04 13:19 ` Cyril Hrubis
2024-11-04 13:32 ` Cyril Hrubis
2024-11-04 15:59 ` Petr Vorel
2024-11-12 21:23 ` Petr Vorel
2024-11-13 13:44 ` Cyril Hrubis
2024-11-04 14:16 ` Petr Vorel [this message]
2024-11-12 12:50 ` Martin Doucha
2024-11-12 21:40 ` Petr Vorel
2024-11-13 14:02 ` Martin Doucha
2024-11-13 14:50 ` Petr Vorel
2024-11-13 13:48 ` Cyril Hrubis
2024-11-28 8:27 ` 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=20241104141606.GB1388681@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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