From: Theodore Ts'o <tytso@mit.edu>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Cc: aneesh.kumar@linux.vnet.ibm.com, balbir@linux.vnet.ibm.com,
Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>,
"Theodore Ts'o" <tytso@mit.edu>,
linux-fsdevel@vger.kernel.org
Subject: [PATCH -V2] ext3: provide function to release metadata pages under memory pressure
Date: Mon, 8 Dec 2008 09:06:42 -0500 [thread overview]
Message-ID: <1228745203-743-1-git-send-email-tytso@mit.edu> (raw)
In-Reply-To: <20081208140138.GA17700@mit.edu>
From: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Pages in the page cache belonging to ext3 data files are released via
the ext3_releasepage() function specified in the ext3 inode's
address_space_ops. However, metadata blocks (such as indirect blocks,
directory blocks, etc) are managed via the block device
address_space_ops, and they can not be released by
try_to_free_buffers() if they have a journal head attached to them.
To address this, we supply a release_metadata function which is called
by the block device's blkdev_releasepage() function, which calls
journal_try_to_free_buffers() function to free the metadata.
Signed-off-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-fsdevel@vger.kernel.org
---
fs/ext3/inode.c | 29 +++++++++++++++++++++++++++++
fs/ext3/super.c | 2 ++
include/linux/ext3_fs.h | 2 ++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index f8424ad..89c065a 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -1680,6 +1680,35 @@ static int ext3_releasepage(struct page *page, gfp_t wait)
}
/*
+ * Try to release metadata pages (indirect blocks, directories) which are
+ * mapped via the block device. Since these pages could have journal heads
+ * which would prevent try_to_free_buffers() from freeing them, we must use
+ * jbd layer's try_to_free_buffers() function to release them.
+ *
+ * Note: we have to strip the __GFP_WAIT flag before calling
+ * journal_try_to_free_buffers because blkdev_releasepage is
+ * called while holding a spinlock (bdev_inode.client_lock).
+ * Fortunately the metadata buffers we are interested are freed right
+ * away and do not require calling journal_wait_for_transaction_sync_data().
+ */
+int ext3_release_metadata(void *client, struct page *page, gfp_t wait)
+{
+ struct super_block *sb = (struct super_block*)client;
+ journal_t *journal;
+
+ WARN_ON(PageChecked(page));
+ if (!page_has_buffers(page))
+ return 0;
+ BUG_ON(EXT3_SB(sb) == NULL);
+ journal = EXT3_SB(sb)->s_journal;
+ if (journal != NULL)
+ return journal_try_to_free_buffers(journal, page,
+ wait & ~__GFP_WAIT);
+ else
+ return try_to_free_buffers(page);
+}
+
+/*
* If the O_DIRECT write will extend the file then add this inode to the
* orphan list. So recovery will truncate it back to the original size
* if the machine crashes during the write.
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 541d5e4..4428149 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2981,6 +2981,8 @@ static struct file_system_type ext3_fs_type = {
.name = "ext3",
.get_sb = ext3_get_sb,
.kill_sb = kill_block_super,
+ .release_metadata
+ = ext3_release_metadata,
.fs_flags = FS_REQUIRES_DEV,
};
diff --git a/include/linux/ext3_fs.h b/include/linux/ext3_fs.h
index 9004794..3e3052f 100644
--- a/include/linux/ext3_fs.h
+++ b/include/linux/ext3_fs.h
@@ -867,6 +867,8 @@ extern void ext3_get_inode_flags(struct ext3_inode_info *);
extern void ext3_set_aops(struct inode *inode);
extern int ext3_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
u64 start, u64 len);
+extern int ext3_release_metadata(void *client, struct page *page,
+ gfp_t wait);
/* ioctl.c */
extern int ext3_ioctl (struct inode *, struct file *, unsigned int,
--
1.6.0.4.8.g36f27.dirty
next prev parent reply other threads:[~2008-12-08 14:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-02 11:06 [BUG][PATCH 1/4] ext3: fix a cause of __schedule_bug via blkdev_releasepage Toshiyuki Okajima
2008-12-08 14:01 ` Theodore Tso
2008-12-08 14:06 ` Theodore Ts'o [this message]
2008-12-08 14:06 ` [PATCH -V2] ext4: provide function to release metadata pages under memory pressure Theodore Ts'o
2008-12-12 0:54 ` [BUG][PATCH 1/4] ext3: fix a cause of __schedule_bug via blkdev_releasepage Toshiyuki Okajima
2008-12-12 6:21 ` Theodore Tso
2008-12-12 17:52 ` [PATCH -v3] vfs: add releasepages hooks to block devices which can be used by file systems Theodore Ts'o
2008-12-12 17:52 ` [PATCH -v3] ext3: provide function to release metadata pages under memory pressure Theodore Ts'o
2008-12-12 17:52 ` [PATCH -v3] ext4: " Theodore Ts'o
2008-12-17 15:39 ` [PATCH -v3] vfs: add releasepages hooks to block devices which can be used by file systems Jan Kara
2008-12-18 5:15 ` Toshiyuki Okajima
2008-12-18 13:12 ` Jan Kara
2008-12-18 14:54 ` Theodore Tso
2008-12-18 16:38 ` Jan Kara
2008-12-19 5:15 ` Toshiyuki Okajima
2008-12-26 5:01 ` Al Viro
2009-01-03 15:09 ` Theodore Ts'o
2009-01-03 15:09 ` [PATCH 1/3] add releasepage " Theodore Ts'o
2009-01-03 15:09 ` [PATCH 2/3] ext3: provide function to release metadata pages under memory pressure Theodore Ts'o
2009-01-03 15:09 ` [PATCH 3/3] ext4: " Theodore Ts'o
2009-01-05 8:16 ` [PATCH 1/3] add releasepage hooks to block devices which can be used by file systems Toshiyuki Okajima
2009-01-05 16:05 ` Theodore Tso
2009-01-06 4:07 ` Toshiyuki Okajima
2009-01-06 4:29 ` Theodore Tso
2008-12-15 2:21 ` [BUG][PATCH 1/4] ext3: fix a cause of __schedule_bug via blkdev_releasepage Toshiyuki Okajima
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=1228745203-743-1-git-send-email-tytso@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=toshi.okajima@jp.fujitsu.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;
as well as URLs for NNTP newsgroup(s).