From: Ted Ts'o <tytso@mit.edu>
To: Brian King <brking@linux.vnet.ibm.com>
Cc: Josef Bacik <josef@redhat.com>,
linux-ext4@vger.kernel.org, cmm@linux.vnet.ibm.com,
pmac@au1.ibm.com
Subject: Re: [PATCHv2 1/1] jbd2: Fix I/O hang in jbd2_journal_release_jbd_inode
Date: Fri, 27 Aug 2010 15:10:25 -0400 [thread overview]
Message-ID: <20100827191025.GV4453@thunk.org> (raw)
In-Reply-To: <4C3E08E6.2050203@linux.vnet.ibm.com>
On Wed, Jul 14, 2010 at 01:58:46PM -0500, Brian King wrote:
>
> I've been debugging a hang in jbd2_journal_release_jbd_inode
> which is being seen on Power 6 systems quite a lot. When we get
> in the hung state, all I/O to the disk in question gets blocked
> where we stay indefinitely. Looking at the task list, I can see
> we are stuck in jbd2_journal_release_jbd_inode waiting on a
> wake up. I added some debug code to detect this scenario and
> dump additional data if we were stuck in jbd2_journal_release_jbd_inode
> for longer than 30 minutes. When it hit, I was able to see that
> i_flags was 0, suggesting we missed the wake up.
>
> This patch changes i_flags to be an unsigned long, uses bit operators
> to access it, and adds barriers around the accesses. Prior to applying
> this patch, we were regularly hitting this hang on numerous systems
> in our test environment. After applying the patch, the hangs no longer
> occur. Its still not clear to me why the j_list_lock doesn't protect us
> in this path. It also appears a hang very similar to this was seen
> in the past and then was no longer recreatable:
I've been look at this patch, and I can see how converting to bitops
definitely makes sense. I can also see how adding
smp_mb__after_clear_bit() makes sense. However, it's not clear the
smp_mb() call here helps?
> diff -puN fs/jbd2/journal.c~jbd2_ji_commit_barrier_patch fs/jbd2/journal.c
> --- linux-2.6/fs/jbd2/journal.c~jbd2_ji_commit_barrier_patch 2010-07-14 13:46:17.000000000 -0500
> +++ linux-2.6-bjking1/fs/jbd2/journal.c 2010-07-14 13:46:17.000000000 -0500
> @@ -2209,9 +2211,10 @@ void jbd2_journal_release_jbd_inode(jour
> restart:
> spin_lock(&journal->j_list_lock);
> /* Is commit writing out inode - we have to wait */
> - if (jinode->i_flags & JI_COMMIT_RUNNING) {
> + if (test_bit(__JI_COMMIT_RUNNING, &jinode->i_flags)) {
> wait_queue_head_t *wq;
> DEFINE_WAIT_BIT(wait, &jinode->i_flags, __JI_COMMIT_RUNNING);
> + smp_mb();
> wq = bit_waitqueue(&jinode->i_flags, __JI_COMMIT_RUNNING);
> prepare_to_wait(wq, &wait.wait, TASK_UNINTERRUPTIBLE);
> spin_unlock(&journal->j_list_lock);
- Ted
next prev parent reply other threads:[~2010-08-27 19:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-14 14:56 [PATCH 1/1] jbd2: Fix I/O hang in jbd2_journal_release_jbd_inode Brian King
2010-07-14 16:32 ` Eric Sandeen
2010-07-14 16:39 ` Brian King
2010-07-14 16:40 ` Eric Sandeen
2010-07-14 17:44 ` Josef Bacik
2010-07-14 18:58 ` [PATCHv2 " Brian King
2010-07-14 19:05 ` Josef Bacik
2010-07-14 20:08 ` Brian King
2010-07-21 14:01 ` Brian King
2010-07-21 19:02 ` Jan Kara
2010-07-21 19:06 ` Jan Kara
2010-07-22 21:30 ` Brian King
2010-08-27 19:10 ` Ted Ts'o [this message]
2010-08-27 19:28 ` Brian King
2010-08-31 14:04 ` Brian King
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=20100827191025.GV4453@thunk.org \
--to=tytso@mit.edu \
--cc=brking@linux.vnet.ibm.com \
--cc=cmm@linux.vnet.ibm.com \
--cc=josef@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=pmac@au1.ibm.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.