On Thu, 2011-11-03 at 16:44 -0400, J. Bruce Fields wrote: > I'm feeling dense. > > On Wed, Nov 02, 2011 at 11:54:53AM -0400, Jeff Layton wrote: > > Yes, I think it is different. When we truncate the file to 0 then we > > don't care if another write races in. > > Client 1 Client 2 > -------- -------- > > setattr size to 0 > write to file > get change attribute > > If we decide not to invalidate the cache here, then we miss Client 2's > write. The same is true if we set the size to something other than 0. ????????? How can we "decide not to invalidate the cache here"? the call to nfs_vmtruncate() will _always_ call truncate_pagecache(). The only case where we don't call nfs_vmtruncate() is if the client has already determined that the file size was zero, and optimised away the setattr call altogether. > There's a second possible race when Client 2's write comes before the > setattr, and it's true that that race doesn't matter in the size-0 case > and does in the other. > > But if we were doing a write instead of a setattr, we'd ignore that > second race. > > And I don't understand why something like ftruncate should be treated > differently from write. In either case we're modifying a file while > holding a write open, and I'd expect us to assume in both cases that > nobody else is doing the same. When did we move to the topic of multiple clients, and why do you think it is relevant? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
