From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH] XFS: Don't flush stale inodes
Date: Sat, 2 Jan 2010 13:39:40 +1100 [thread overview]
Message-ID: <1262399980-19277-1-git-send-email-david@fromorbit.com> (raw)
Because inodes remain in cache much longer than inode buffers do
under memory pressure, we can get the situation where we have stale,
dirty inodes being reclaimed but the backing storage has been freed.
Hence we should never, ever flush XFS_ISTALE inodes to disk as
there is no guarantee that the backing buffer is in cache and
still marked stale when the flush occurs.
Signed-off-by: Dave Chinner <david@fromorbit.com>
---
fs/xfs/xfs_inode.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index c2618db..e5c9953 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2846,10 +2846,14 @@ xfs_iflush(
mp = ip->i_mount;
/*
- * If the inode isn't dirty, then just release the inode
- * flush lock and do nothing.
+ * If the inode isn't dirty, then just release the inode flush lock and
+ * do nothing. Treat stale inodes the same; we cannot rely on the
+ * backing buffer remaining stale in cache for the remaining life of
+ * the stale inode and so xfs_itobp() below may give us a buffer that
+ * no longer contains inodes below. Doing this stale check here also
+ * avoids forcing the log on pinned, stale inodes.
*/
- if (xfs_inode_clean(ip)) {
+ if (xfs_inode_clean(ip) || xfs_iflags_test(ip, XFS_ISTALE)) {
xfs_ifunlock(ip);
return 0;
}
--
1.6.5
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2010-01-02 2:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-02 2:39 Dave Chinner [this message]
2010-01-02 12:00 ` [PATCH] XFS: Don't flush stale inodes Christoph Hellwig
2010-01-02 12:14 ` Dave Chinner
2010-01-02 12:24 ` Dave Chinner
2010-01-02 13:17 ` Christoph Hellwig
2010-01-02 13:39 ` Dave Chinner
2010-01-08 20:59 ` Alex Elder
2010-01-08 23:14 ` [PATCH v2] xfs: " Alex Elder
2010-01-09 0:09 ` Dave Chinner
2010-01-09 16:22 ` Alex Elder
2010-01-09 22:39 ` Dave Chinner
2010-01-10 16:43 ` Alex Elder
2010-01-09 18:10 ` [PATCH, updated] xfs: Ensure we force all busy extents in range to disk Alex Elder
2010-01-09 19:35 ` Christoph Hellwig
2010-01-10 18:28 ` [PATCH, updated] xfs: Ensure we force all busy extents inrange " Alex Elder
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=1262399980-19277-1-git-send-email-david@fromorbit.com \
--to=david@fromorbit.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