On Mon, Jul 08, 2013 at 07:21:37PM +0000, Myklebust, Trond wrote: > On Mon, 2013-07-08 at 14:53 -0400, Bruce Fields wrote: > > On Mon, Jul 08, 2013 at 06:10:40PM +0000, Myklebust, Trond wrote: > > > On Mon, 2013-07-08 at 10:17 -0400, Bruce Fields wrote: > > > > On Fri, Jul 05, 2013 at 05:46:19PM -0400, Jeff Layton wrote: > > > > > I think the bigger issue though is that looking at refcounts in order to > > > > > determine when we have a conflicting open is just plain wrong. There are > > > > > all sorts of reasons one might see a raised refcount that don't involve > > > > > conflicting opens (Al's stat() example for instance). It seems like we > > > > > ought to shoot for a solution that doesn't rely (solely) on inode and > > > > > dentry refcounts. > > > > > > > > Note that NFSv4 write delegations will need to affect stat as well. > > > > (Once you let a client perform writes locally, that client becomes the > > > > authority on the attributes, so we have to call back to it on stat.) > > > > > > Umm... Yes, but are we ever really going to want to implement that part > > > of the spec? All the client can tell you is 'this file is dirty' and/or > > > it can tell you that a size change has occurred. > > > > > > It's cute that the protocol allows you to do this, but it's not > > > particularly practical. > > > > If we don't take some sort of action on stat then I don't see how to > > avoid e.g. breaking "make". > > We already cache writes without breaking "make". Why do you think the > presence of a delegation must necessarily change everything? As long as it holds a write delegation a client can delay updating data or attributes arbitrarily--so if the server continues to return the old attributes then e.g. "make" could fail to notice an update even long after no application on any client is accessing the file any more. Could you explain what I'm missing? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
