From: Ted Ts'o <tytso@mit.edu>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, rwheeler@redhat.com,
sandeen@redhat.com, adilger@dilger.ca, snitzer@gmail.com
Subject: Re: [PATCH 0/6 v4] Lazy itable initialization for Ext4
Date: Tue, 28 Sep 2010 11:05:24 -0400 [thread overview]
Message-ID: <20100928150524.GD7865@thunk.org> (raw)
In-Reply-To: <20100928040142.GA7865@thunk.org>
On Tue, Sep 28, 2010 at 12:01:42AM -0400, Ted Ts'o wrote:
> Why are they strange? Because this was running under KVM, and there
> were no underlying hardware problems in the host OS.
>
> The other two times I got a hard hang at XFStests 219 and 83, and the
> system was caught in such a type look that magic-sysrq wasn't working
> correctly.
>
> I've XFStests in this setup before applying these patches, and things
> worked fine. I'm currently rolling back the patches and trying
> another xfstests runs just to make sure the problem wasn't introduced
> by some patch, but for now, it looks there might be a problem
> somewhere. And unfortunately, since it's not happening in a regular
> location or test, and the system is so badly locked up sysrq doesn't
> work, finding it may be intersting....
I've just tried bisecting the patches, and tried applying the first
three (well, two since I combined patches #2 and #3). Simply enabling
the init_itables code wasn't enough to trigger the problem. It looks
like the problem is in the last three patches (probably in one of the
patches where we convert ext4 to use sb_issue_zeroout, either the
extent or the resize code).
What I'll probably do (unless we find the problem very quickly) is to
reorder things so that we take the init_itable patch and the sysfs
feature patch, and put the rest into the unstable portion of the patch
queue. That way I can work on the rest of the ext4 patches for the
merge window, without getting blocked on this patch series. And if we
don't manage to figure out what went wrong, while it would be nice to
simplify the code for 2.6.36, it won't be the end of the world if they
need to wait until the next cycle.
- Ted
next prev parent reply other threads:[~2010-09-28 15:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-16 12:47 [PATCH 0/6 v4] Lazy itable initialization for Ext4 Lukas Czerner
2010-09-16 12:47 ` [PATCH 1/6] Add helper function for blkdev_issue_zeroout Lukas Czerner
2010-09-16 12:47 ` [PATCH 2/6] Add inititable/noinititable mount options for ext4 Lukas Czerner
2010-09-27 18:35 ` Ted Ts'o
2010-09-16 12:47 ` [PATCH 3/6] Add inode table initialization code for Ext4 Lukas Czerner
2010-09-16 12:47 ` [PATCH 4/6] Use sb_issue_zeroout in setup_new_group_blocks Lukas Czerner
2010-09-29 14:12 ` Lukas Czerner
2010-09-29 14:14 ` Lukas Czerner
2010-10-01 16:00 ` [PATCH 4/6 fixed] " Lukas Czerner
2010-09-16 12:47 ` [PATCH 5/6] Use sb_issue_zeroout in ext4_ext_zeroout Lukas Czerner
2010-09-16 12:47 ` [PATCH 6/6] Add interface to advertise ext4 features in sysfs Lukas Czerner
2010-09-28 4:01 ` [PATCH 0/6 v4] Lazy itable initialization for Ext4 Ted Ts'o
2010-09-28 15:05 ` Ted Ts'o [this message]
2010-09-29 13:37 ` Lukas Czerner
2010-10-01 15:58 ` Lukas Czerner
2010-10-02 19:55 ` Ted Ts'o
2010-10-03 2:43 ` Ted Ts'o
2010-10-04 2:36 ` Ted Ts'o
2010-10-04 7:31 ` Ted Ts'o
2010-10-04 13:14 ` Lukas Czerner
2010-10-04 13:19 ` Lukas Czerner
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=20100928150524.GD7865@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=sandeen@redhat.com \
--cc=snitzer@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).