From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage()
Date: Sat, 16 Mar 2013 18:35:08 +1100 [thread overview]
Message-ID: <20130316073508.GI6369@dastard> (raw)
In-Reply-To: <1363267854-25602-1-git-send-email-jack@suse.cz>
On Thu, Mar 14, 2013 at 02:30:54PM +0100, Jan Kara wrote:
> When a dirty page is truncated from a file but reclaim gets to it before
> truncate_inode_pages(), we hit WARN_ON(delalloc) in
> xfs_vm_releasepage(). This is because reclaim tries to write the page,
> xfs_vm_writepage() just bails out (leaving page clean) and thus reclaim
> thinks it can continue and calls xfs_vm_releasepage() on page with dirty
> buffers.
>
> Fix the issue by redirtying the page in xfs_vm_writepage(). This makes
> reclaim stop reclaiming the page and also logically it keeps page in a
> more consistent state where page with dirty buffers has PageDirty set.
>
> Signed-off-by: Jan Kara <jack@suse.cz>
Definitely look s like a problem taht needs fixing, and it seems to
me to be the correct fix.
I got a bug report recently about this warning being triggered,
but the total report was the warning and a workload description
of "XFS produced a warning at some point during a 28 hour long DB
benchmark." Not particularly helpful, but this looks like a
potential cause. Thanks!
Cheers,
Dave.
--
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:[~2013-03-16 7:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 13:30 [PATCH] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage() Jan Kara
2013-03-14 20:21 ` Carlos Maiolino
2013-03-15 20:52 ` Ben Myers
2013-03-18 16:05 ` Jan Kara
2013-03-19 3:47 ` Dave Chinner
2013-03-19 15:42 ` Jan Kara
2013-03-21 1:37 ` Dave Chinner
2013-03-22 21:12 ` Ben Myers
2013-03-16 7:35 ` Dave Chinner [this message]
2013-03-22 23:18 ` Ben Myers
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=20130316073508.GI6369@dastard \
--to=david@fromorbit.com \
--cc=jack@suse.cz \
--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 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.