From: tytso@mit.edu
To: jing zhang <zj.barak@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
linux-ext4 <linux-ext4@vger.kernel.org>,
Andreas Dilger <adilger@sun.com>,
Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Subject: Re: [PATCH] ext4: memory leakage in ext4_mb_init()
Date: Mon, 5 Apr 2010 08:42:23 -0400 [thread overview]
Message-ID: <20100405124223.GN18524@thunk.org> (raw)
In-Reply-To: <o2tac8f92701004042208l99c70297mf9955beacacd96bf@mail.gmail.com>
On Mon, Apr 05, 2010 at 01:08:58PM +0800, jing zhang wrote:
>
> Before linux-2.6.32 is released, would you like tell me, how is ext4 tested?
> Is tough testing able to catch all bugs?
For one thing, we use the XFSQA (aka xfstests) test suite. I usually
run the "quick" set of tests between each commit, and I run a much
longer "auto" test suite before submitting a set of patches to Linus.
For specific patches, we also like to be able to test it specifically.
So often we'll create a small filesystem image and then see what the
file system does with and without the patch. For example, if we're
worried that a specific file system corruption will cause a BUG_ON,
we'll create a small file system, corrupt it using the debugfs tool,
and then demonstrate that without the patch, we get the BUG_ON. With
the patch applied, the BUG_ON should go away.
So the patch-specific tests are there so we can make sure the patch
does what we think it should, and it fixes the problem it claims to
fix. The XFSQA test suite is to there to make sure that we don't
accidentally introduce bugs while trying to improve the file system.
And of course, the final safeguard is patch review by others. This is
where decent comments and making sure the code is maintainable is
critically important. Since this takes other developer's time,
especially senior developers like Eric and myself's time, which is
rather valuable and hard to find, it's why patch submitters need
shoulder more of the work in terms of refining patches and
resubmitting new versions of the patches.
- Ted
P.S. Yes, Eric was absolutely correct. I wanted to know how much
testing you had been doing on your patches before submitting them. At
least few of your patches have caused me to wonder whether the patches
had gone through sufficient testing.
next prev parent reply other threads:[~2010-04-05 12:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-21 14:01 [PATCH] ext4: memory leakage in ext4_mb_init() jing zhang
2010-03-22 1:27 ` tytso
2010-03-23 12:47 ` jing zhang
2010-03-26 8:57 ` Aneesh Kumar K. V
2010-03-26 14:40 ` jing zhang
2010-03-28 8:13 ` jing zhang
2010-04-03 16:53 ` tytso
2010-04-04 1:05 ` jing zhang
2010-04-04 18:08 ` tytso
2010-04-05 3:53 ` jing zhang
2010-04-05 4:27 ` Eric Sandeen
2010-04-05 4:51 ` jing zhang
2010-04-05 4:59 ` Eric Sandeen
2010-04-05 5:08 ` jing zhang
2010-04-05 12:42 ` tytso [this message]
2010-04-06 13:43 ` jing zhang
2010-04-06 14:21 ` tytso
2010-04-07 16:34 ` jing zhang
2010-04-05 5:18 ` jing zhang
2010-04-05 12:43 ` tytso
2010-03-26 8:54 ` Aneesh Kumar K. V
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=20100405124223.GN18524@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=shaggy@linux.vnet.ibm.com \
--cc=zj.barak@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).