Re: nfs_file_flush() question

[Trond Myklebust <trond.myklebust@fys.uio.no>]

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