From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH v2 0/5] ext4: try to fix up es regressions
Date: Fri, 8 Mar 2013 21:18:41 +0800 [thread overview]
Message-ID: <20130308131841.GD18986@gmail.com> (raw)
In-Reply-To: <87ppzbgpkg.fsf@openvz.org>
On Thu, Mar 07, 2013 at 08:08:47PM +0400, Dmitry Monakhov wrote:
> On Wed, 6 Mar 2013 22:17:10 +0800, Zheng Liu <gnehzuil.liu@gmail.com> wrote:
> > Hi all,
> >
> > The patch series tries to fixup some regressions after applied the extent
> > status tree. These patches have rebased against the latest dev branch of
> > ext4 and have been tested by xfstests.
> >
> > After rebased the latest dev branch, two patches have been dropped because
> > they have been applied into the branch. A new patch is added, which tries
> > to fix up a wrong return value in ext4_split_extent(). Otherwise, there
> > are two major changes in this version. The first one is to improve the
> > self-testing-infrastructure according to Dmitry's comment. The second one
> > is to improve the zero out code.
> >
> > After applied this patch series, I havn't seen the warning messages from
> > self-testing infrastructure except the following cases.
> >
> > - xfstests #13 with bigalloc or with no journal
> > - xfstests #223 with dioread_nolock
> > The reason is that when we lookup a block mapping from status tree
> > i_data_sem locking won't be taken. So there is a race window that an
> > unwritten extent could be converted by end_io when we compare the result
> > between extent tree and status tree.
> >
> > Dmitry, Ted, could you please confirm that this patch series can fix the
> > defrag regression? Thank you so much. Until now I run #300 and #301 a
> > lot times but I failed to hit this regression. :-(
> Good work. All my tests now succeed (no error, no warning, no bugons),
Great! Thanks for your confirmation.
> BUT 301'th (in terms of git://oss.sgi.com/xfs/cmds/xfstests.git)
> result in massive memory leakage
> about 8gb in an hour
> #while true; do ./check 301 ;done
> I suspect that 'struct ext4_ext_path' is leaked somewhere, I'm not
> even sure that it is new one.
Thanks for the reminder. Maybe there still has some bugs in extent
tree. I will look at it.
Regards,
- Zheng
next prev parent reply other threads:[~2013-03-08 13:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 14:17 [PATCH v2 0/5] ext4: try to fix up es regressions Zheng Liu
2013-03-06 14:17 ` [PATCH v2 1/5] ext4: improve ext4_es_can_be_merged() to avoid a potential overflow Zheng Liu
2013-03-11 0:43 ` Theodore Ts'o
2013-03-11 6:03 ` Zheng Liu
2013-03-06 14:17 ` [PATCH v2 2/5] ext4: add self-testing infrastructure to do a sanity check Zheng Liu
2013-03-07 15:41 ` Dmitry Monakhov
2013-03-08 13:01 ` Zheng Liu
2013-03-11 1:01 ` Theodore Ts'o
2013-03-06 14:17 ` [PATCH v2 3/5] ext4: fix wrong m_len value after unwritten extent conversion Zheng Liu
2013-03-07 15:42 ` Dmitry Monakhov
2013-03-11 1:07 ` Theodore Ts'o
2013-03-11 5:47 ` Zheng Liu
2013-03-13 1:57 ` Theodore Ts'o
2013-03-13 2:14 ` Theodore Ts'o
2013-03-13 8:53 ` Zheng Liu
2013-03-06 14:17 ` [PATCH v2 4/5] ext4: update extent status tree after an extent is zeroed out Zheng Liu
2013-03-07 15:55 ` Dmitry Monakhov
2013-03-08 13:14 ` Zheng Liu
2013-03-06 14:17 ` [PATCH v2 5/5] ext4: fix wrong the number of the allocted blocks in ext4_split_extent Zheng Liu
2013-03-06 22:58 ` Dev branch regressions Theodore Ts'o
2013-03-07 2:40 ` Zheng Liu
2013-03-07 6:47 ` Lukáš Czerner
2013-03-07 11:54 ` Zheng Liu
2013-03-07 16:08 ` [PATCH v2 0/5] ext4: try to fix up es regressions Dmitry Monakhov
2013-03-08 13:18 ` Zheng Liu [this message]
2013-03-11 2:11 ` Theodore Ts'o
2013-03-11 6:23 ` Zheng Liu
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=20130308131841.GD18986@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wenqing.lz@taobao.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.