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". (That action doesn't necessarily have to be a CB_GETATTR to the client and a blind return of the results.) --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
