From: Eric Sandeen <sandeen@redhat.com>
To: Mark Brown <ntdeveloper2002@yahoo.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Filesystem testing
Date: Thu, 06 Feb 2014 22:48:41 -0600 [thread overview]
Message-ID: <52F465A9.5030004@redhat.com> (raw)
In-Reply-To: <1391728596.39450.YahooMailNeo@web141003.mail.bf1.yahoo.com>
On 2/6/14, 5:16 PM, Mark Brown wrote:
> Thanks for all the answers Eric:-)
>
> I did have one question, and this was more related to ext3, and possible to xfstests.
>
> Is there a test suite for ext3 that tests the various corruption
> issues, bugs that have been detected, and has other tests as well?
> Kind of a suite that is run everytime a change is made. I know its a
> question about a very old filesys, if I should direct my question
> elsewhere, do let me know. Maybe the generic in xfstests is enough
> for that, I couldnt find ext3 specific tests for the harness anywhere
> else. Is there a separate Redhat test suite (assuming ext3 was being
> maintained by RH)?
>
> Is xfstests for ext4 basically used for ext4 for the question I asked
> about ext3 above?
we do still support & help with ext3, yes - and xfstests is still useful
for that. It does not cover every bugfix, but the generic/shared
xfstests still have fairly decent generic ext3 coverage.
One could always write more tests if interested. :)
-Eric
> Thanks.
>
>
>
>
>
>
>
>
> On Wednesday, February 5, 2014 7:31 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> 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
>
>>
>
> --
> 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
>
> --
> 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
>
next prev parent reply other threads:[~2014-02-07 4:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-05 23:20 Filesystem testing Mark Brown
2014-02-06 2:00 ` Eric Sandeen
2014-02-06 3:12 ` Mark Brown
2014-02-06 3:31 ` Eric Sandeen
2014-02-06 23:16 ` Mark Brown
2014-02-07 4:48 ` Eric Sandeen [this message]
2014-02-06 9:45 ` Lukáš Czerner
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=52F465A9.5030004@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ntdeveloper2002@yahoo.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).