From: Joel Becker <joel.becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 3/3] ocfs2: Local mounts should not truncate the extent map.
Date: Wed Mar 28 18:51:01 2007 [thread overview]
Message-ID: <20070329005717.809593000@oracle.com> (raw)
In-Reply-To: 20070329005041.518030000@oracle.com
A local mount can implicitly trust state on the inode. There are no other
nodes to change the filesystem. Thus, local mounts should leave the extent
map intact until ->clear_inode().
This fixes a bug where a call to ocfs2_meta_lock_update() can race queries
of the extent map. A clustered mount only allows one process through
ocfs2_meta_lock_update(), but a local mount allows all processes through.
Thus, one process can be all the way to ocfs2_extent_map_get_blocks() when
a second process is truncating the extent map in ocfs2_meta_lock_update().
That no longer happens because the extent map is unmodified.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
---
fs/ocfs2/dlmglue.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index e335541..eb1c8fa 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -1508,8 +1508,9 @@ static int ocfs2_meta_lock_update(struct
ocfs2_metadata_cache_purge(inode);
/* will do nothing for inode types that don't use the extent
- * map (directories, bitmap files, etc) */
- ocfs2_extent_map_trunc(inode, 0);
+ * map (bitmap files, etc) */
+ if (!ocfs2_mount_local(osb))
+ ocfs2_extent_map_trunc(inode, 0);
if (lockres && ocfs2_meta_lvb_is_trustable(inode, lockres)) {
mlog(0, "Trusting LVB on inode %llu\n",
--
1.4.2.3
next prev parent reply other threads:[~2007-03-28 18:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-28 18:50 [Ocfs2-devel] [PATCH 0/3] Properly protect the extent map Joel Becker
2007-03-28 18:50 ` [Ocfs2-devel] [PATCH 1/3] ocfs2: Wrap access of directory allocations with ip_alloc_sem Joel Becker
2007-03-28 18:51 ` [Ocfs2-devel] [PATCH 2/3] ocfs2: Properly lock extent map size changes Joel Becker
2007-03-28 18:51 ` Joel Becker [this message]
2007-03-29 2:04 ` [Ocfs2-devel] [PATCH 0/3] Properly protect the extent map Fabio Massimo Di Nitto
2007-03-29 9:41 ` Sunil Mushran
2007-04-02 11:45 ` Mark Fasheh
2007-04-02 11:48 ` Fabio Massimo Di Nitto
2007-04-02 11:58 ` Mark Fasheh
2007-04-02 12:00 ` Fabio Massimo Di Nitto
2007-04-02 11:47 ` Mark Fasheh
2007-04-02 16:55 ` Joel Becker
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=20070329005717.809593000@oracle.com \
--to=joel.becker@oracle.com \
--cc=ocfs2-devel@oss.oracle.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.