[Top] [All Lists]

Re: [PATCH] ext4: add fallocate mode blocking for debugging purposes

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] ext4: add fallocate mode blocking for debugging purposes
From: Theodore Ts'o <tytso@xxxxxxx>
Date: Wed, 16 Apr 2014 01:47:47 -0400
Cc: Eric Sandeen <sandeen@xxxxxxxxxx>, LukÃÅ Czerner <lczerner@xxxxxxxxxx>, Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx>, Namjae Jeon <linkinjeon@xxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=ef5046eb; t=1397627267; bh=Oubi9wejipf876hMbA0ubb9iejMwABJCc5PO1cvdw3g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wBKMmMg1I3b3rWzZ+/r0R2Z71gWyIKa9uZu7iZSz2tQfEa1PFWMxhkduzJ08Avft+ 1/zDatDVsAP0kViiiwaFtkl838jDZoMJL4R3L2n9w9ELQCe7Oby64XwbI46DnhyUBs wgtHRR10AqlfNZ8EUSEw5s2g0zxijlrB/vSC2Gdo=
In-reply-to: <20140416000634.GT15995@dastard>
References: <1397420518-29218-1-git-send-email-tytso@xxxxxxx> <20140413220016.GD8122@xxxxxxxxx> <alpine.LFD.2.00.1404151749490.2146@xxxxxxxxxxxxxxxxxxxxx> <534D5B2D.70408@xxxxxxxxxx> <20140415184442.GC4456@xxxxxxxxx> <534DB38B.7030805@xxxxxxxxxx> <20140415233039.GR4456@xxxxxxxxx> <20140416000634.GT15995@dastard>
User-agent: Mutt/1.5.23 (2014-03-12)
On Wed, Apr 16, 2014 at 10:06:35AM +1000, Dave Chinner wrote:
> > Some of the work that I've
> > been doing with kvm-xfstests and why I created a github tytso/xfstests
> > git tree is specifically to make sure things go much more smoothly
> > this time around.
> Ted, this looks and sounds like you're preparing to fork xfstests.
> Why?  What's the problem with working upstream on test development
> and refinement like everyone else does?

I'd prefer not to fork xfstests.  However, I do want to get more ext4
developers using automated xfstests testing, so I can scale better.
In order to do that, I need to be able to make it really easy for
people to who aren't hard-core xfstests people to be able to use it.

One of the nice things about kvm-xfstests is that a *lot* easier for
people to figure out how to use it.  If I can lower the activation
energy required to get people to use xfstests, it saves me time in the

The reason why I created the github repository is because if I'm going
to be shipping a KVM test appliance image that people can use in a
turn-key environment, I'd prefer that all of the sources, including
any local changes that I might need to make the tests run as smoothly
as possible, are available in a public repository.  (And at one point,
I did have up to 12 local changes, which is why I wanted it tracked in
a repo.)

Every single local change I made was either a test or commit that
hadn't been accepted into the upstream xfstests repository yet, or a
fix I wrote that I sent upstream.  And as soon as the fixes made it
into the upstream xfstests repository, I rebased them away.  At the
moment, there's only once commit in my xfstests github repository
which isn't upstream and it's the:

  check: add support for an external file containing tests to exclude

commit for which I've sent the V2 version to you.

So for the most part, I want to keep the repo as close to upstream as
possible, and ideally identical to upstream, and I've been working
towards that end.

> This thread is a demonstration of how avoiding upstream interaction
> results in nasty hacks being proposed. If you asked the question on
> the xfs mailing list of how to avoid various fsstress/fsx
> operations, we woul dhave told you that using FSSTRESS_AVOID and
> adding an equivalent FSX_AVOID to xfstests is all that is needed.
> i.e. we already have partial infrastructure support for what you
> need in xfstests and it would be about 30 minutes work to add
> Is that fast enough for you?
> Indeed, we could also use similar env vars to ensure various
> _requires_* checks fail and to populate FSSTRESS_AVOID/FSX_AVOID
> automatically and so tests that require this functionality are not
> run.

Well, it took me about 1 minute to write the dozen line kernel patch.
I really didn't want to ask you to make changes to xfstests for me,
but if you're willing to make those changes, that would be great.  I
really didn't want to presume, though.  And if the answer is that I
need to spend the time making all of these changes --- I'll try, but
if I don't have time, I may end up taking the more expedient path.

> IOWs, it's in your best interests to work with upstream to add the
> functionality you require to xfstests. History tells us that forking
> development into private repositories has never worked out well for
> anyone, so I'd really, really like you to *at least try* to work
> with upstream as your primary test development environment....

As I said, every single patch which I put in my local xfstests tree I
also sent upstream.

That being said, I wasn't sure whether you were going to accept that
last change, since there was similar, but for me, not usable
functionality in the form of the -X option.  So if you weren't going
to accept a change to allow the excluded list of tests to be kept in a
single file outside of the tests/* subdirectory, I probably would have
carried it as a separate patch --- because it's something I need, and
the current -X functionality really isn't easy to maintain (you need
to have many more files, and they have to be dropped into the xfstests
tests/* subdirectory).

I know that you and I haven't seen eye to eye in the past.  For
example, the NO_HIDE_STALE out of tree patch which is running on
thousands and thousands numbers of machines inside Google, but which
the XFS folks have considered evil incarnate.  I will freely admit
that I'm much more of a pragmatist and much less of a purist on
certain matters.

So sure, I'm certainly going to _try_ to work with upstream xfstests.
I've done that to date.  But I'm certainly not going to presume that
you're going to like or accept all of the changes I might want to


                                                - Ted

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