I think that patch introduces a problem. Since the checking for the change in ctime was removed by the commit it leads to (improper) cache invalidation in NFSv3. Test is write 10240bytes to the server then read it. Expectation is not to see read on the wire. In the test the write is spread over 3rpcs. On the 1nd reply fattr->gencount=33 nfsi->gencount=32 generation_counter=35 On the 2nd reply fattr->gencount=34 nfsi->gencount=36 generation_counter=36 In the code when processing 2nd reply, nfs_post_op_update_inode_force_wcc_locked() calls into nfs_inode_attrs_need_update() it determines that it doesn't need to update them (even though the size and the time have changed). so it doesn't call nfs_wcc_update_inode() so the inode->i_version doesn't get set to the ctime that was received in the 2nd reply. On the 3rd reply fattr->gencount=37 nfsi->gencount=36 generation_counter=37 It leads to nfs_inode_attrs_need_update() returns 1 and in the nfs_update_inode() the difference in the ctimes leads to invalidation. fattr->gencount was update from nfs_writeback_update_node() -> nfs_post_op_update_inode_force_wcc() calling nfs_fattr_set_barrier(). I'm not sure what appropriate values for "gencount" should have been. But if the check for nfs_ctime_need_update() was still there in nfs_inode_attrs_need_update() then the 2nd reply would have appropriately updated the i_version and not lead to invalidation. -- 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
