Message-ID: <20140403173504.GB23737@thunk.org>
Date:	Thu, 3 Apr 2014 13:35:04 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Lukáš Czerner <lczerner@...hat.com>,
	Dave Chinner <david@...morbit.com>, xfs@....sgi.com,
	lsf@...ts.linux-foundation.org,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of
 CPUs in build-all

On Thu, Apr 03, 2014 at 10:05:26AM -0700, Andy Lutomirski wrote:
> 
> virtme will eventually be able to use a separate OS image, probably in
> the form of a directory with appropriate xattrs set.  I could support
> images on a block device too, but that's boring :)

When you say OS image, you mean "root file system, right"?  One of the
reasons why I'm actually build an actual root-file system image, and
didn't try the virtme approach was that I wanted to boot 32-bit
kernels on my development machine, which is 64-bit.

Having a 32-bit chroot environment would certainly work, though, and
would save the effort of creating the root file system image....  (and
of course having a 32-bit userspace also is a great way of exercising
the ioctl compatibility code paths :-).

> from inside a virtme checkout.  You'll have to compile xfstests first, though.

Fortunately, xfstests-bld will handle do this for you, since it grabs
and builds all of the depedencies automatically.  More importantly, it
allows the dependencies to be saved as part of the test output since
that's important when trying to have other people understand how to
reproduce a particular test result (since sometimes the latest
xfstests requires the latest xfs_io from xfsprogs, so it's a bad idea
to depend on the version of xfsprogs shipped by your distribution).
For example, for this merge window, I've been using the following to
do my tests:

fio		fio-2.1-19-g0b14f0a (Thu, 23 May 2013 21:27:54 +0200)
quota		0d0a674 (Tue, 26 Mar 2013 17:13:33 +0100)
xfsprogs	v3.2.0-alpha2-60-gaa210c4 (Thu, 13 Mar 2014 21:23:50 +1100)
xfstests-bld	1efde7a (Tue, 1 Apr 2014 14:42:07 -0400)
xfstests	linux-v3.8-336-g3948694 (Thu, 13 Mar 2014 15:20:54 +1100)

> They will be considerably more useful once I add read-write host
> windows to virtme.

Yes, you definitely want that for the results directories.

>  - There's an undocumented way to write results outside the source
> tree called RESULT_BASE.  It would be great if it were documented and
> spelled consistently.

There are a bunch of inconsistencies, which I've chalked up to
historical accidents and a desire to not break compatibility with
developers' test runners.  You mount the $SCRATCH_DIR on SCRATCH_MNT
but you mount $TEST_DEV on $TEST_DIR, for example.  I've just learned
to live with it....

>  - SCRATCH_MNT needs to be in /etc/fstab.  I think that this should be
> changed or documented.  If the latter, then SCRATCH_DEV seems
> redundant.

The various test scripts do need to be able to find the device where
the file system lives, and parsing /etc/fstab would be awkward.  So if
your comment is that either the /etc/fstab entry shouldn't be
required, or the xfstests runtime environment should be able to derive
$SCRATCH_DEV automatically from $SCRATCH_MNT, or vice versa, instead
of having the user specify both, I'd agree that would be nice, but
that's why I put together scripts like the ones I have in xfstests-bld
--- to make life easier.  :-)

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists