Re: [RFC] F_SETLEASE mess

["Myklebust, Trond" <Trond.Myklebust@netapp.com>]

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?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com