From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: check for stale inode before acquiring iflock on push
Date: Tue, 12 Jun 2012 10:12:21 +1000 [thread overview]
Message-ID: <20120612001221.GH22848@dastard> (raw)
In-Reply-To: <1339425583-54949-1-git-send-email-bfoster@redhat.com>
On Mon, Jun 11, 2012 at 10:39:43AM -0400, Brian Foster wrote:
> An inode in the AIL can be flush locked and marked stale if
> a cluster free transaction occurs at the right time. The
> inode item is then marked as flushing, which causes xfsaild
> to spin and leaves the filesystem stalled. This is
> reproduced by running xfstests 273 in a loop for an
> extended period of time.
>
> Check for stale inodes before the flush lock. This marks
> the inode as pinned, leads to a log flush and allows the
> filesystem to proceed.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>
> This patch resolves the stall I was reproducing with the 273 loop test.
> I repeated the test pretty much throughout the weekend. I still hit one
> hung task timeout message, but the test proceeded through it.
>
> Dave, I know you mentioned you were sending a similar patch. Either you
> didn't get to it or I missed it, but here's what I've been testing....
Just didn't get to sending it - it was a holiday yesterday. The
patch is identical, though the commit message is a bit different:
xfs: inode staleness more important than flushing for AIL
When we have a dirty stale inode, it must be attached to the
underlying stale buffer and that means it is flush locked. This
means that the AIL pushing will only ever see flushing inodes, and
that means if enough of them are built up at the start of the AIL we
will never trigger a log force from the AIL to get them moving.
Hence consider the stale state of inodes more important to report
than whether they are flushing so as to trigger log forces from the
AIL more readily in this situation.
Otherwise, consider it:
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-12 0:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 14:39 [PATCH] xfs: check for stale inode before acquiring iflock on push Brian Foster
2012-06-11 18:39 ` Mark Tinguely
2012-06-12 0:18 ` Dave Chinner
2012-06-12 0:12 ` Dave Chinner [this message]
2012-06-15 12:40 ` Christoph Hellwig
2012-06-18 14:29 ` Mark Tinguely
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=20120612001221.GH22848@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=xfs@oss.sgi.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