All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Michael Rubin <mrubin@google.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] clear PAGECACHE_TAG_DIRTY for truncated pages
Date: Fri, 1 Feb 2008 20:18:47 +0800	[thread overview]
Message-ID: <401868346.26085@ustc.edu.cn> (raw)
Message-ID: <E1JKur1-0001Dh-Ol@localhost.localdomain> (raw)

The `truncated' page in block_write_full_page()/nobh_writepage() may
stick for a long time.  For example, ext2_rmdir() will set i_size to
0, and then the dir inode and its pages may hang around because of
being referenced by some process.

To produce this situation:

In terminal 1:
                $ mkdir hi; cd hi
                $ sleep 1h; cd ..
In terminal 2:
                $ rmdir hi

The dir 'hi' is deleted in terminal 2 while still being referenced by
the shell(as working dir) in terminal 1.  The deleted inode 'hi' with
its dirty-and-truncated page will stay for 1 hour, during which the
pdflush will retry the page _at least_ once every 5s.

So clear PAGECACHE_TAG_DIRTY to prevent pdflush from retrying on it.

Tested-by: Joerg Platte <jplatte@naasa.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Michael Rubin <mrubin@google.com>
Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
---
 fs/buffer.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+)

--- linux-mm.orig/fs/buffer.c
+++ linux-mm/fs/buffer.c
@@ -2631,7 +2631,13 @@ int nobh_writepage(struct page *page, ge
 		if (page->mapping->a_ops->invalidatepage)
 			page->mapping->a_ops->invalidatepage(page, offset);
 #endif
+		/*
+		 * Clear PAGECACHE_TAG_DIRTY to stop pdflush from retrying.
+		 * Read block_write_full_page() for more details.
+		 */
+		set_page_writeback(page);
 		unlock_page(page);
+		end_page_writeback(page);
 		return 0; /* don't care */
 	}
 
@@ -2826,7 +2832,17 @@ int block_write_full_page(struct page *p
 		 * freeable here, so the page does not leak.
 		 */
 		do_invalidatepage(page, 0);
+		/*
+		 * Clear PAGECACHE_TAG_DIRTY to stop pdflush from retrying.
+		 *
+		 * Some truncated pages may hang around for long time.
+		 * For example, ext2_rmdir() will set i_size to 0, and then
+		 * keep the pages as long as the dir is still referenced(as
+		 * the working dir of some process).
+		 */
+		set_page_writeback(page);
 		unlock_page(page);
+		end_page_writeback(page);
 		return 0; /* don't care */
 	}
 


                 reply	other threads:[~2008-02-01 12:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=401868346.26085@ustc.edu.cn \
    --to=wfg@mail.ustc.edu.cn \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrubin@google.com \
    --cc=peterz@infradead.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 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.