linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Zheng Liu <gnehzuil.liu@gmail.com>
Cc: linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>,
	Dmitry Monakhov <dmonakhov@openvz.org>
Subject: Dev branch regressions
Date: Wed, 6 Mar 2013 17:58:18 -0500	[thread overview]
Message-ID: <20130306225818.GA13277@thunk.org> (raw)
In-Reply-To: <1362579435-6333-1-git-send-email-wenqing.lz@taobao.com>

On Wed, Mar 06, 2013 at 10:17:10PM +0800, Zheng Liu wrote:
> 
> *Big Note*
> When I am testing this patch series, I found some regressions in dev branch.
> Here is a note.  These regressions could be hitted by running test case
> serveral times.  So If we just run xfstests one time, they could be missed.
> 
>  - xfstests #74 with data=journal
> 
>  - xfstests #247 with data=journal
> Some warning messages are printed by ext4_releasepage.  We hit
> WARN_ON(PageChecked(page)) in this function.  But the test case itself can
> pass.
> 
>  - xfstests #269 with dioread_nolock
> The system will hang

I'm going to guess that you were running this using your SSD test
setup?  I just ran:

kvm-xfstests -c data_journal 74,74,74,74,74,247,247,247,247,247

using my standard hdd setup, and didn't see any failures or warnings.

How frequently are you seeing these failures?  When I have a chance
I'll try running these tests with a tmpfs image and see if I have any
better luck reproducing the problem there.

I did manage to get a hang (preceded with a soft lockup for the
dioread_nolock with test 269).

>  - xfstests #83 with bigalloc
> Some threads could be blocked for 120s.

I've seen this test blocked for hours (but without managing to trigger
the 120s soft lockup warning), but I'm not entirely sure this was a
regression.  I believe I've seen a similar hang with 3.8.0-rc3 if I
recall correctly.  I had been hoping the changes with the extent
status tree would fix it, but apparently no such luck.  :-(

> I don't paste full details here to make description clearly.  I will go on
> tracing these problems.  I am happy to provide full details if some one
> want to take a close look at these problems.

If you have a chance, please do send e-mails with each failure
separated out in a separate e-mail with different subject line so it's
easier for others to follow along.

Thanks!!

						- Ted

  parent reply	other threads:[~2013-03-06 22:58 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 ` Theodore Ts'o [this message]
2013-03-07  2:40   ` Dev branch regressions 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
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=20130306225818.GA13277@thunk.org \
    --to=tytso@mit.edu \
    --cc=dmonakhov@openvz.org \
    --cc=gnehzuil.liu@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --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 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).