On Mon, 2013-07-08 at 17:17 -0400, Bruce Fields wrote:
> On Mon, Jul 08, 2013 at 08:14:05PM +0000, Myklebust, Trond wrote:
> > 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.
>
> To reduce the latency of the close operation? The RFCs clearly permit
> it.
>
> But I know you know that, so I think you're saying that the mechanisms
> described in the rfc don't work as the authors seemed to intend, and any
> careful client will be required to do something on close anyway.
>
> Is that correct? Could you explain your thinking?
>
> I believe you--and I'll be delighted to get out of having to hook
> stat--but I don't see it yet.
>
> It looks to me like the server can implement write delegations by either
> 1) breaking delegations on every stat or 2) doing a cb_getattr on stat
> and then recalling only if the return indicates the client has dirty
> data.
Why must you recall if you the cb_getattr shows dirty data? Just bumping
the change attribute should suffice to keep 'make' and friends happy.
They can then trigger the recall by deciding to open the file.
> Is your argument that this will require breaking delegations too
> frequently to make write delegations practical, hence that clients and
> server will still have to depend on clients doing some minimal update of
> the file on close?
Yes. Right now, our client does relax the rules to not send the COMMIT;
the write delegation ensures that we can recover safely in case of a
server reboot. However we do still actively flush out the WRITEs to
reduce the burden of delegation recalls, and also to ensure that we
don't have to worry about the whole delegation writeback quota
business...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
