From: Eric Sandeen <sandeen@redhat.com>
To: chrubis@suse.cz, "Theodore Ts'o" <tytso@mit.edu>
Cc: Luk???? Czerner <lczerner@redhat.com>,
Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>,
linux-ext4@vger.kernel.org
Subject: Re: OpenPosix test case mmap_11-4 fails in ext4 filesystem
Date: Wed, 21 May 2014 17:06:06 -0500 [thread overview]
Message-ID: <537D234E.7060304@redhat.com> (raw)
In-Reply-To: <20140521212003.GA7493@rei.suse.cz>
On 5/21/14, 4:20 PM, chrubis@suse.cz wrote:
> Hi!
>> There is a pretty large amount of overlap between LTP and xfstests,
>> and xfstests are what most of the file system developers are using,
>> and we have developed a lot of automated test automation which means
>> running xfstests is very easy and convenient. For example:
>>
>> https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/README
>>
>> The ability for me to build a kernel and then with a single command,
>> "kvm-xfstests smoke", do a quick verification in about 30 minutes, is
>> very convenient.
>
> LTP is automated to a degree where you run single script and get a file
> with list of failed testcases later. We do not have any kind of kvm
> integration though.
>
>> As I recall, ltp was integrated with autotest, and my experience with
>> autotest at multiple companies is if anything, worse than ltp's
>> reputation. (I considered ltp to be mostly harmless, albeit not
>> particularly useful, whereas I considered autotest to be activetly
>> harmful to engineer productivity.)
>
> The autotest integration is not a part of the LTP at all. I remember
> seeing it somewhere but I've never used it/looked at the code.
>
> LTP has it's own script and testdriver to run testcases, but given that
> LTP tests are just binaries that are mostly self-contained it's not
> doing much more than starting a test, writing logfiles and killing
> lefover processes (if the tests fails to collect them itself). I will
> not pretend that it's clean and well designed code but at least it works
> fine (as a matter of fact I've started to work on redesigning/rewriting
> it from scratch some time ago).
>
>> Anyway, it's already the case that most of the useful file-system
>> specific bits of LTP has been cherry picked into xfstests, and I
>> suspect it will be a lot easier to get a few additional LTP test cases
>> added into xfstests, than it will be to convince a large number of
>> file system developers that they should (a) try to figure out how to
>> integrate LTP into their test harnesses, and (b) how to avoid
>> duplicating tests which xfstests are already running.
>
> Well I can personally help with (a).
>
> The test in question here (mmap_11-4) is a part of the Open Posix
> Testsuite that continues to live in LTP. The whole testsuite runs in
> about 30 minutes and covers most of the POSIX interfaces in ~1600
> testcases.
>
> Then there is a syscalls testsuite which covers, in addition to the
> POSIX specs, some of the Linux specific interfaces too. The runtime is
> about 15 minutes for ~1030 testcases.
>
> I guess that we can filter filesystem related syscalls quite easily. The
> overlap would take more work though. In LTP we have mostly conformance
> testcases and some stress testcases. I'm not much familiar with xfstests
> and its coverage.
>
> And we have a more tests that may be interesting to fs maintaners, there
> are aio testcases (which are likely covered by xfstests allready), some
> fs stress tests, ...
>
FWIW, I don't think there's any real compelling reason to migrate existing
LTP tests into xfstests. Maybe LTP folks just need to do a better job of
pitching LTP to filesystem developers, as we did with xfstests. :)
-Eric
next prev parent reply other threads:[~2014-05-21 22:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 6:39 OpenPosix test case mmap_11-4 fails in ext4 filesystem Xiaoguang Wang
2014-05-21 12:55 ` Lukáš Czerner
2014-05-21 14:12 ` Theodore Ts'o
2014-05-21 15:06 ` chrubis
2014-05-21 18:58 ` Theodore Ts'o
2014-05-21 21:20 ` chrubis
2014-05-21 22:06 ` Eric Sandeen [this message]
2014-05-22 2:45 ` Theodore Ts'o
2014-05-22 10:45 ` chrubis
2014-05-22 14:38 ` Theodore Ts'o
2014-05-21 15:18 ` Lukáš Czerner
2014-05-21 19:01 ` Theodore Ts'o
2014-05-22 13:42 ` Jan Kara
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=537D234E.7060304@redhat.com \
--to=sandeen@redhat.com \
--cc=chrubis@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wangxg.fnst@cn.fujitsu.com \
/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).