From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Zheng Liu <gnehzuil.liu@gmail.com>
Subject: Re: ext4 xfstest regression due to ext4_es_lookup_extent
Date: Sat, 23 Feb 2013 13:37:06 +0400 [thread overview]
Message-ID: <87txp3cqwt.fsf@openvz.org> (raw)
In-Reply-To: <20130222180325.GB21264@thunk.org>
On Fri, 22 Feb 2013 13:03:25 -0500, "Theodore Ts'o" <tytso@mit.edu> wrote:
> On Fri, Feb 22, 2013 at 09:17:57PM +0400, Dmitry Monakhov wrote:
> >
> > 301'th xfstests are failed due to :
> > commit d100eef2440fea13e4f09e88b1c8bcbca64beb9f
> > Author: Zheng Liu <wenqing.lz@taobao.com>
> > Date: Mon Feb 18 00:29:59 2013 -0500
> >
> > ext4: lookup block mapping in extent status tree
> >
> > TESTCASE: https://github.com/dmonakhov/xfstests/commit/7b7efeee30a41109201e2040034e71db9b66ddc0
>
> Thanks for the heads up. I haven't updatied the xfstests I've been
> using yet, since I want to make sure I'm comparing apples and oranges
> during the merge window when I'm checking for regressions; I'll update
> my xfstests in a week or two after the merge window settles down, and
> then I'll rerun my baseline tests using the updated xfstests against
> 3.8.0 and 3.9-rc2 or 3.9-rc3.
>
> (And furthermore, these new xfstests aren't yet in xfstests upstream
> yet, right? Any comments from the xfstests maintainer about whether
> they are going to be willing to take your proposed new test cases?)
I hope so. I think i've fixed things according to Dave's commit.
> So when you say this is a regression, I take it that this test #301
> doesn't fail on commit d100eef2440f^, but it does fail on d100eef2440f,
> correct?
Correct. d100ee is the first bad commit which trigger BUGON()
But issue was introduced earlier es_cache was not updated
after extents was swapped between inodes.
I'll prepare patch soon.
Actually I think that the regression in 269'th you have found recently
caused by similar issue and commit which you foud by bisecting ( the one
which allow migration between indirect<->extent based inodes)
simply helps to spot real issue in es_caching code.
BUT my main idea is that we need robust self-testing infrastructure
similar one that we have at the time extents was introduced to ext4.
>
> - Ted
next prev parent reply other threads:[~2013-02-23 9:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 17:17 ext4 xfstest regression due to ext4_es_lookup_extent Dmitry Monakhov
2013-02-22 18:03 ` Theodore Ts'o
2013-02-23 9:37 ` Dmitry Monakhov [this message]
2013-02-23 10:00 ` Zheng Liu
2013-02-24 0:14 ` Theodore Ts'o
2013-02-24 3:21 ` Zheng Liu
2013-02-26 23:18 ` [PATCH] jbd2: Fix ERR_PTR dereference in jbd2__journal_start Dmitry Monakhov
2013-03-02 22:10 ` Theodore Ts'o
2013-02-23 5:36 ` ext4 xfstest regression due to ext4_es_lookup_extent Zheng Liu
2013-02-24 14:58 ` Zheng Liu
2013-02-25 8:39 ` Dmitry Monakhov
2013-02-25 9:57 ` Zheng Liu
2013-02-26 20:06 ` Theodore Ts'o
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=87txp3cqwt.fsf@openvz.org \
--to=dmonakhov@openvz.org \
--cc=gnehzuil.liu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--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.