All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ted Ts'o <tytso@mit.edu>
Cc: Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>,
	Michael Rubin <mrubin@google.com>,
	Eric Sandeen <sandeen@redhat.com>,
	linux-ext4@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Drop ext2/ext3 codebase? When?
Date: Tue, 22 Feb 2011 10:48:43 +1100	[thread overview]
Message-ID: <20110221234843.GE3166@dastard> (raw)
In-Reply-To: <20110215172922.GG4255@thunk.org>

On Tue, Feb 15, 2011 at 12:29:22PM -0500, Ted Ts'o wrote:
> On Tue, Feb 15, 2011 at 03:28:37PM +1100, Dave Chinner wrote:
> > 
> > What scripts are needed? xfstests has the $MKFS_OPTIONS and
> > $MOUNT_OPTIONS environment variables for customising your mkfs and
> > mount parameters for each test run, so isn't testing ext3
> > filesystems with the ext4 code should just be a matter of setting
> > these appropriately?
> 
> Correct, this doesn't require changes to xfstests.
> 
> What is needed for this ext4/ext3-using-ext4 testing is a wrapper
> script *around* xfstests that sets up the enviornment variables
> correctly, and uses different devices for the "common case"
> combinations of mkfs and mount options (where we would keep an aged
> file system around), and for those devices which we don't think are
> valuable enough to dedicate a reserved file system image, we'd have to
> mkfs a special version of that filesystem for TEST_DEV.

Every developer has their own set of wrapper scripts for doing just
this. Every test environment is different, so I'm not sure there is
a one-size-fits-all script waiting here.

In the past I've considered extending this sort of test
configuration to the configuration files and adding a command line
parameter to select the config file that defines the test setup. I
think you can specify the config file via the HOST_OPTIONS env
variable right now, but I haven't looked any further than that.

FWIW, I keep all my config files in a patch I apply to my xfstests
git repo before I rsync it to all my test machines, so this approach
would work for me, too. ;)

> (I'm not sure why xfstests doesn't use freshly created file in the
> case where SCRATCH_DEV is defined by TEST_DEV is not, but it doesn't;

I'm not sure what you are asking for here...

> as far as I know there are no tests where it uses both TEST_DEV and
> SCRATCH_DEV, is there?)

There are tests that do this (e.g. 073) - maybe none of the
generic tests do right now, but there are XFS specific tests that
do.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2011-02-21 23:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 14:40 [LSF/MM TOPIC] Drop ext2/ext3 codebase? When? Jan Kara
2011-02-03 15:08 ` Eric Sandeen
2011-02-03 19:32   ` Michael Rubin
2011-02-03 19:49     ` Eric Sandeen
2011-02-03 21:57       ` Amir Goldstein
2011-02-03 22:00         ` Eric Sandeen
2011-02-04 13:59         ` Jan Kara
2011-02-04  0:04     ` Ted Ts'o
2011-02-04 13:17     ` Jan Kara
2011-02-04 17:03       ` Ric Wheeler
2011-02-04 17:17         ` [Lsf-pc] " James Bottomley
2011-02-05 18:43           ` Trond Myklebust
2011-02-07 17:21           ` Mingming Cao
2011-02-12 11:05       ` Amir Goldstein
2011-02-14 17:25         ` Jan Kara
2011-02-14 19:00           ` Amir Goldstein
2011-02-14 19:58             ` Ted Ts'o
2011-02-14 20:59               ` Andreas Dilger
2011-02-14 21:22               ` Amir Goldstein
2011-02-15  4:28               ` Dave Chinner
2011-02-15 17:29                 ` Ted Ts'o
2011-02-21 23:48                   ` Dave Chinner [this message]
2011-02-04 13:03   ` Jan Kara
2011-02-04 17:36     ` Andreas Dilger
2011-02-07 16:19       ` Jan Kara
2011-02-07 16:35         ` Andreas Dilger
2011-02-11 11:16           ` Jan Kara
2011-02-11 18:44             ` Michael Rubin

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=20110221234843.GE3166@dastard \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mrubin@google.com \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.