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.
--
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�����٥
