On Wed, Nov 02, 2011 at 07:07:42AM -0400, Jeff Layton wrote: > On Tue, 1 Nov 2011 21:23:15 -0400 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > On Tue, Nov 01, 2011 at 08:43:25PM -0400, Jeff Layton wrote: > > > On Tue, 1 Nov 2011 16:07:27 -0700 > > > "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > > > > Is the problem perhaps that we should be clearing the > > > > NFS_INO_INVALID_DATA flag in nfs_vmtruncate() when the size gets set to > > > > zero? > > > > > > > > > > That was my thinking too. Whenever we truncate the i_size to 0, we > > > can safely assume that the pagecache is now valid, and should be able > > > to clear NFS_INO_INVALID_DATA no matter when it was set, right? > > > > I don't understand why 0 is a special case: why should my setting the > > size ever mean that I have to go reread data from the server? > > > > If the server doesn't send pre-op attrs (and linux servers don't) then > you have no way to know whether someone raced in and did writes to the > remaining pages just prior to your truncate. > > Size 0 is a special case because there are no remaining pages. Those 3rd-party writes could also arrive between the truncate and the read of the post-op attrs. Is this setattr/write conflict really any different than write/write conflicts? In both cases you've got a file open for write on two different clients. And we live with the same sort of race in the write/write case. (Hence the nfs_post_op_update_inode_force_wcc in nfs4_write_done_cb.) --b. -- 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
