On Tue, 2008-08-19 at 15:17 -0500, Quentin Barnes wrote: > > If I don't know the correct mtime attribute of the file when I close it, > > If I follow the code, you do know the mtime when closing the > file. With V3, from the WRITE and COMMIT, you're given weak cache > consistency data containing the the updated mtimes, correct? No. Please note the difference between a call to nfs_update_inode(), and a call to nfs_refresh_inode(). The latter tries to be more careful about updating the inode attributes if there is a chance that we may have raced with another RPC call to the same inode, and hence that the attributes returned may be stale. > But making the change to nfs_revalidate_inode() by itself only > helps in the case where the file was open O_RDWR and no write(2) > was done. The code still needed to be updated to use the WCC data > at the right time. In the older kernels when nfs_wb_all() ended up > calling nfs_update_inode() which was clearing the cache when it saw > the mtime change from the WRITE. I tracked down why. Newer kernels > (2.6.24 and later) had nfs_post_op_update_inode_force_wcc() call > added to nfs3_write_done() which updated the inode with the WCC data > from the WRITE so the later call to nfs_update_inode() didn't see > an unexpected mtime change flagging the attribute and data cache as > invalid. See above. Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
