Re: Filesystem testing

[Eric Sandeen <sandeen@redhat.com>]

On 2/5/14, 9:12 PM, Mark Brown wrote:
> Thanks Eric.
> 
> I am looking at the README here:
> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git;a=blob_plain;f=README;hb=HEAD
> 
> 
> Is this what you are referring to? It doesnt seem to have much information about the tests.

Well, no, that's true.  There's no great summary of the tests; buit each test in tests/*/???
should have at least a brief description at the top.

There's also a tests/*/group file which has keywords for each test, so you can do
i.e. ./check -g stress to run all tests tagged with "stress"

> Should I look here?
> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git;a=tree;f=tests;h=a8535b21d5b45a7653bc0f4e2774d3b94871ba2e;hb=HEAD

well, there you can see the entire history of changes, so ... sure!  :)

> 
> I did have some questions:-)
> 
> 1. Do the tests do operations other than the POSIX operations? I see
> different directories for xfs etc, which would imply it does some
> filesys specific calls?

yes; it's just a test harness, it can test whatever we like.

Some of the xfs tests do test xfs-specific operations.  Ditto for ext4 tests.
Other tests are more generic.

> 2. There are some other test tools like Iozone which have similar
> functionality. Wanted to understand what the differences would be, in
> using xfstests as opposed to them?

iozone is a benchmark, not a test suite.  It measures performance, not correctness.

> 3. is xfstests more of a test suite geared for developers? Is it something a QA org can use

Our QA organization makes good use of it, as do others.  So, sure.

And best of all it's open source so if your organization comes across
a bug, you can submit a testcase, and the bug should never(tm) happen again.

> 4. What I am looking for is a tool which I can use to stress the file
> system a lot, do different operations etc, and make sure the data
> written and metadata and the filesys itself is consistent by
> verifying it at the end. You mentioned testing IO failures as well
> and consistency is checked at the end. If you can point me to a few
> tests that do the stress test and IO failures for the generic case,
> that would really help, just to make sure i dont misunderstand the
> tests when I am looking through the sources.

Start by reading the tests themselves; for example, tests/generic/311:

# Run various fsync tests with dm flakey in freeze() mode and non freeze()
# mode. The idea is that we do random writes and randomly fsync and verify that
# after a fsync() followed by a freeze()+failure or just failure that the file
# is correct.  We remount the file system after the failure so that the file
# system can do whatever cleanup it needs to and md5sum the file to make sure
# it matches hat it was before the failure.  We also fsck to make sure the file
# system is consistent.

-Eric

> Thanks:-)
> 
>  
> 
> 
> 
> On Wednesday, February 5, 2014 6:01 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> On 2/5/14, 5:20 PM, Mark Brown wrote:
>> As an aside, I looked at xfstests, from what I could gather, it was
>> started only for xfs, but there is ongoing work to make it work with
>> ext4(and thus other posix FS?). If someone can point me to the
>> documentation for xfstests and what it does, that would help. I could
>> not find much.
> 
> xfstests has gone pretty far beyond just xfs at this point - it's seen
> heavy use on ext2/3/4 as well as btrfs in the past several years.
> 
> There is a README in the git repo; did you have specific questions?
> 
> We have a lot of tests in there; some are general stress tests, some
> are specific regression tests, and the body of tests is always growing.
> 
> Some test IO failures, as well.  File system consistency is checked after
> each test.  Etc...
> 
> -Eric
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>