Re: [RFC] F_SETLEASE mess

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

On Mon, 2013-07-08 at 15:34 -0400, Bruce Fields wrote:
> 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?

An explanation for why the client would want to do this.

-- 
Trond Myklebust
Linux NFS client maintainer

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