linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: <linux-fsdevel@vger.kernel.org>
Cc: Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	Wu Fengguang <fengguang.wu@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/7] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY
Date: Thu, 20 Oct 2011 23:22:42 +0800	[thread overview]
Message-ID: <20111020153705.882281372@intel.com> (raw)
In-Reply-To: 20111020152240.751936131@intel.com

[-- Attachment #1: mutt-wfg-hp-1000-22575-612225d7a6295ddc6 --]
[-- Type: text/plain, Size: 2015 bytes --]

From: Christoph Hellwig <hch@infradead.org>

Right now ->write_inode has no way to safely return a EAGAIN without explicitly
redirtying the inode, as we would lose the dirty state otherwise.  Most
filesystems get this wrong, but XFS makes heavy use of it to avoid blocking
the flusher thread when ->write_inode hits contentended inode locks.  A
contended ilock is something XFS can hit very easibly when extending files, as
the data I/O completion handler takes the lock to update the size, and the
->write_inode call can race with it fairly easily if writing enough data
in one go so that the completion for the first write come in just before
we call ->write_inode.

Change the handling of this case to use requeue_io_wait for a quick retry instead
of redirty_tail, which keeps moving out the dirtied_when data and thus keeps
delaying the writeout more and more with every failed attempt to get the lock.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
 fs/fs-writeback.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

--- linux-next.orig/fs/fs-writeback.c	2011-10-08 13:30:25.000000000 +0800
+++ linux-next/fs/fs-writeback.c	2011-10-08 13:30:41.000000000 +0800
@@ -488,8 +488,18 @@ writeback_single_inode(struct inode *ino
 			 * operations, such as delayed allocation during
 			 * submission or metadata updates after data IO
 			 * completion.
+			 *
+			 * For the latter case it is very important to give
+			 * the inode another turn on b_more_io instead of
+			 * redirtying it.  Constantly moving dirtied_when
+			 * forward will prevent us from ever writing out
+			 * the metadata dirtied in the I/O completion handler.
+			 *
+			 * For files on XFS that constantly get appended to
+			 * calling redirty_tail means they will never get
+			 * their updated i_size written out.
 			 */
-			redirty_tail(inode, wb);
+			requeue_io_wait(inode, wb);
 		} else {
 			/*
 			 * The inode is clean.  At this point we either have

  parent reply	other threads:[~2011-10-20 15:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-20 15:22 [PATCH 0/7] writeback: avoid touching dirtied_when on blocked inodes Wu Fengguang
2011-10-20 15:22 ` [PATCH 1/7] writeback: introduce queue b_more_io_wait Wu Fengguang
2011-10-20 23:23   ` Jan Kara
2011-10-20 15:22 ` Wu Fengguang [this message]
2011-10-20 23:24   ` [PATCH 2/7] writeback: avoid redirtying when ->write_inode failed to clear I_DIRTY Jan Kara
2011-10-20 15:22 ` [PATCH 3/7] writeback: update wb->last_active on written pages/inodes Wu Fengguang
2011-10-20 15:22 ` [PATCH 4/7] writeback: Retry kupdate work early if we need to retry some inode writeback Wu Fengguang
2011-10-20 15:22 ` [PATCH 5/7] writeback: requeue_io_wait() on pages_skipped inode Wu Fengguang
2011-10-20 23:25   ` Jan Kara
2011-10-20 15:22 ` [PATCH 6/7] writeback: requeue_io_wait() on blocked inode Wu Fengguang
2011-10-20 23:31   ` Jan Kara
2011-10-20 15:22 ` [PATCH 7/7] writeback: requeue_io_wait() when failed to grab superblock Wu Fengguang
2011-10-20 23:25   ` Jan Kara
2011-10-20 23:21 ` [PATCH 0/7] writeback: avoid touching dirtied_when on blocked inodes Jan Kara
2011-10-21 10:40   ` Wu Fengguang
2011-10-21 19:54     ` Jan Kara
2011-10-22  3:11       ` Wu Fengguang
2011-10-22  5:38         ` Wu Fengguang
2011-10-22  6:59           ` Wu Fengguang
2011-10-22  7:07             ` Wu Fengguang
2011-10-22  7:46           ` Wu Fengguang
2011-10-22  4:46 ` Wu Fengguang

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=20111020153705.882281372@intel.com \
    --to=fengguang.wu@intel.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    /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).