[Top] [All Lists]

Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs

To: "Theodore Ts'o" <tytso@xxxxxxx>
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all
From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
Date: Thu, 3 Apr 2014 10:42:54 -0700
Cc: Lukáš Czerner <lczerner@xxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, lsf@xxxxxxxxxxxxxxxxxxxxxxxxxx, Linux FS Devel <linux-fsdevel@xxxxxxxxxxxxxxx>, Sedat Dilek <sedat.dilek@xxxxxxxxx>, "linux-ext4@xxxxxxxxxxxxxxx" <linux-ext4@xxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140403173504.GB23737@xxxxxxxxx>
References: <1395997399-3000-1-git-send-email-sedat.dilek@xxxxxxxxx> <20140328161806.GA31772@xxxxxxxxx> <20140331025148.GF16336@dastard> <20140401023711.GE4911@xxxxxxxxx> <20140401222823.GJ17603@dastard> <20140402142620.GA6901@xxxxxxxxx> <20140403011411.GL16336@dastard> <alpine.LFD.2.00.1404031102310.2124@xxxxxxxxxxxxxxxxxxxxx> <CALCETrU=JWigDSv6ymepS2tjL+EkO98VDC03-RSPuhQVk3yvZA@xxxxxxxxxxxxxx> <20140403173504.GB23737@xxxxxxxxx>
On Thu, Apr 3, 2014 at 10:35 AM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> 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.

Yes.  I've actually done this to test some vdso stuff.

> 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 :-).

I agree, as long as there are giant quote marks around chroot.  No
actual chroot would be involved.

I'd like to support non-x86 architectures, too.  Last time I tried to
convince a modern kernel to boot on a released QEMU on ARM was
painful, though.  Maybe -M virt is the way to go here.

The tricky part here is that virtme currently relies on finding a
statically-linked busybox binary in $PATH.  It'll need to learn how to
find one that will run on the guest, or it will need to learn how to
live without busybox.

>> 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)

I haven't actually looked at xfstests-bld yet.  I suspect it could be
made to work with virtme fairly easily.  My current hack uses assumes
you'll use distro packages for all the dependencies.

>> 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....

Given that RESULTS_BASE only occurs in an error message, I think it
could be fixed without breaking compatibility.

>>  - 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

Andy Lutomirski
AMA Capital Management, LLC

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