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 <[EMAIL PROTECTED]>
---
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
_______________________________________________
Ocfs2-devel mailing list
[email protected]
http://oss.oracle.com/mailman/listinfo/ocfs2-devel
