Does anyone remember why we call invalidate_inode_buffers in
invalidate_list? These days we basically call invalidate_inode_buffers
only in ->evict_inode, which we will call from invalidate_list in
case of a zero refcount.
For calls to invalidate_inode_buffers it's hamrless, but for other
callers it means we lose track of which buffers were dirtied for
an inode, and thus can write them out during fsync.
Something like the untested patch below should fix it. While we're
at it - any reaso not to consider I_NEW inodes as busy in
invalidate_list?
Index: linux-2.6/fs/inode.c
===================================================================
--- linux-2.6.orig/fs/inode.c 2010-10-17 16:33:34.826254213 -0700
+++ linux-2.6/fs/inode.c 2010-10-17 16:34:40.407003969 -0700
@@ -570,18 +570,16 @@ static int invalidate_list(struct super_
spin_unlock(&inode->i_lock);
continue;
}
- invalidate_inode_buffers(inode);
- if (!inode->i_ref) {
- WARN_ON(inode->i_state & I_NEW);
- inode->i_state |= I_FREEING;
+ if (inode->i_ref) {
spin_unlock(&inode->i_lock);
-
- /* save a lock round trip by removing the inode here. */
- list_move(&inode->i_sb_list, dispose);
+ busy = 1;
continue;
}
+ inode->i_state |= I_FREEING;
spin_unlock(&inode->i_lock);
- busy = 1;
+
+ /* save a lock round trip by removing the inode here. */
+ list_move(&inode->i_sb_list, dispose);
}
return busy;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
