From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: "Eric Sandeen" <sandeen@redhat.com>,
"Lukáš Czerner" <lczerner@redhat.com>,
"Ext4 Developers List" <linux-ext4@vger.kernel.org>,
"Namjae Jeon" <linkinjeon@gmail.com>
Subject: Re: [PATCH] ext4: add fallocate mode blocking for debugging purposes
Date: Tue, 15 Apr 2014 20:23:46 -0400 [thread overview]
Message-ID: <20140416002346.GA12078@thunk.org> (raw)
In-Reply-To: <20140415232556.GS15995@dastard>
On Wed, Apr 16, 2014 at 09:25:56AM +1000, Dave Chinner wrote:
> Actually, we shouldn't be changing xfstests or adding workarounds in
> the kernel to avoid certain operations. We should be fixing the damn
> bugs that are being exposed.
Well, I'm waiting for Namjae to look into the test failures.
Unfortunately I don't have time right now to fix it myself.
In the meantime, I wanted to do a full baseline test run to make sure
we didn't have any other regressions or failures post -rc1, and so
being able to filter out collapse range allowed me to kick off a test
of the rest of the patches I was hoping to push to Linus for -rc2.
> i.e. that we have to add the FALLOC_FL_INSERT_RANGE to fsx and
> fsstress as well as having corner case tests and it needs to pass
> those tests before XFS support is ready for upstream inclusion. At
> least, that's the lesson I learnt from as the xfstests and XFS
> Maintainer - we didn't put the QA bar for inclusion high enough, and
> so problems slipped through.
>
> If you want to add more strict testing requirements for ext4
> inclusion, then you're welcome to request them for the ext4
> implementation of that functionality. You don't have to accept the
> code until you're happy with it....
No arguments here; I plan to do the same.
Regards,
- Ted
prev parent reply other threads:[~2014-04-16 0:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-13 20:21 [PATCH] ext4: add fallocate mode blocking for debugging purposes Theodore Ts'o
2014-04-13 22:00 ` Theodore Ts'o
2014-04-14 14:05 ` Namjae Jeon
2014-04-16 16:05 ` Lukáš Czerner
2014-04-15 16:02 ` Lukáš Czerner
2014-04-15 16:15 ` Eric Sandeen
2014-04-15 18:44 ` Theodore Ts'o
2014-04-15 19:13 ` Eric Sandeen
2014-04-15 22:32 ` Eric Sandeen
2014-04-15 23:30 ` Theodore Ts'o
2014-04-16 0:06 ` Dave Chinner
2014-04-16 0:06 ` Dave Chinner
2014-04-16 5:47 ` Theodore Ts'o
2014-04-15 23:25 ` Dave Chinner
2014-04-16 0:23 ` Theodore Ts'o [this message]
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=20140416002346.GA12078@thunk.org \
--to=tytso@mit.edu \
--cc=david@fromorbit.com \
--cc=lczerner@redhat.com \
--cc=linkinjeon@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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.