xfs
[Top] [All Lists]

Re: Questions about xfstests regarding porting it to test ext4 filesyst

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Questions about xfstests regarding porting it to test ext4 filesystems
From: Timothy Shimmin <timothy.shimmin@xxxxxxxxx>
Date: Fri, 15 May 2009 08:55:55 +1000
Cc: "Theodore Ts'o" <tytso@xxxxxxx>, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Odl/XmA7+GYxCJA7WOrueEAc63XHIiKH9+6yUt6xHxg=; b=x0zOlRqKHRAZMVg9hmV2w6kFTByxc3E2n29f1FCaiwv12ixpLXXEdV4Eus8Ei8c+1I cf8AnPW08S85RMENsNuRkjqTyqfHKOHvTEl6nsMtriv6iWWkL0PzK0uQYqU0mvAl6RTh VBAakNq5o2JPPg2U7UBKe36ShgzhYaG2Ka+Ns=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cHaFWn86eNqhkaDeLvBSYlk2s+XoU1HKYy/HaOmzJYeSDx0A/3i184YTSz94IpA5oV /qFhPfCBAf/uAu2wsE0wf7zj8HLWRV/isokzahVMQiVSaBTty0f3KvAnx71lQrOEhVNm XuVRgXjI4pQCQh+bY4kCmXKh5vmkwBhgjbp+g=
In-reply-to: <4A0C45AA.3040307@xxxxxxxxxxx>
References: <E1M4aRo-0000ri-0G@xxxxxxxxxxxxxxxxx> <4A0C45AA.3040307@xxxxxxxxxxx>
Hi there,

On Fri, May 15, 2009 at 2:24 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>
> Theodore Ts'o wrote:
>
> > 2)  Why is the TESTDIR have to be a persistent xfs volume?   I noticed
> > that when testing UDF and NFS, the scratch volume is used (and $testdir
> > is set to the point at the scratch directory).   Is there some
> > fundamental reason why there must be an XFS volume mounted, even if the
> > fundamental intention is to test some other filesystem type, whether
> > it's UDF, NFS, or Ext4?
>
> Hm I'll have to dig, not certain.  I thought that TESTDIR would usually
> be used for non-destructive testing, general IO etc, while SCRATCHDIR
> would usually be used for any test that required lots of repeatability,
> and could therefore be more fs-specific.  But that's handwaving.
>
Yeah, I'm not sure if there is a reason to have testdir as a
persistent xfs volume -
in particular I'm not sure on any constraints existing in the tests.
However, the initial TESTDIR intention was to do tests over an ageing filesystem
and one where obviously we didn't need to mkfs over it etc. It exists
and is checked
beforehand and it exists and is checked afterwards.

When doing UDF/IRIX testing we copied over a bunch of xfstests that were general
enough to use on UDF for us. From distant memory, I don't think we
really cared for
a distinction between scratchdir and testdir, and just wanted one
volume to be necessary
for testing (and hence why the main interest for udf was in scratchdir).
Later, someone else ported back the udf tests into the xfstests in an
effort to make
things more filesystem independent.


> > I understand the primary purpose of
> > xfstests has to be to support XFS development, but looking at the
> > scripts, there is a *huge* amount of XFS-specific assumptions all over
> > the shell scripts.  As a result I'm still of two minds whether it will
> > be less work to start from scratch to develop a test suite for ext4 (and
> > from the beginning try to make it filesystem independent) or to try to
> > hack xfstests and try to make it more filesystem indpendent.
>
Tricky ;-)

> Yep, agreed.  I think it's worth evaluating whether the xfstests harness
> is within reach of the goal, though.  But you may be right about how
> much work it is to get there.
>
> Really the value to other filesystems is in the tests (those which are
> or could be made generic), more than the harness, I'd say.
>
I'd agree.
>From memory, the general filesystem handling for mkfs'ing, mounting, checking
and other stuff (in the common file scripts) was a bit messy and error prone.
I think extracting out the useful/fs-generic tests might be more valuable too.
It would be nice to see a clear distinction between filesystem specific tests
and generic ones.

--Tim

<Prev in Thread] Current Thread [Next in Thread>