On Thu, 2011-11-03 at 17:20 -0400, J. Bruce Fields wrote: > On Thu, Nov 03, 2011 at 05:03:05PM -0400, Trond Myklebust wrote: > > 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. > > Sorry, I'm probably using the wrong language. > > I'm using the word "cache" to refer not to the page cache, but more > generally to the client's idea of the file state. Thus if the client, > after the above operation, is left believing the file has size 0, I > wouldn't say it has invalidated its cache, I'd say it's cached the fact > that the file has size zero.... > > Does what I said make sense, given that? Nope; I'm still lost. So if the client is caching a file size of 0, why would it "miss a write"? It will soon see that the file size on the server is non-zero. In fact, your 'get change attribute' will always be accompanied by a 'get file size' that will detect the changed size right there... > > > 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? > > We're seeing the client decide that it can no longer trust its idea of > the file, presumably because it no longer believes it safe to assume > that nobody else has modified it. Did you look into the race I described yesterday? That doesn't require a client 2. -- 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
