Subject: RE: [nfsv4] Open while client has a Delegation

From: Peter Varga <[email-masked]>
Date: Thu, 9 Mar 2006 13:19:50 -0500

Actually Windows has fileids as well on NTFS. It's not a problem at all to
deal with filehandles, I just wanted to clear that up.

So given that a delegation is for all hard links of a file, and a client
knows which files are hard-links, it does not need to send OPEN for the
hard-links either.

Peter

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 1:11 PM
To: Peter Varga
Cc: 'Trond Myklebust'; [email-masked]'; [email-masked]
Subject: Re: [nfsv4] Open while client has a Delegation

On Thu, Peter Varga wrote:
> If a client has locally figured out that an OPEN is to be granted (access
> OK, share/deny bits OK), and it has write delegation for that file, why
> should it send the OPEN to the server ?
> 
> As for hard links, I think we need a clear answer to this question: does a
> delegation apply to all hard links of a file or not? It's controversial
> because OPEN has a file name as a parameter (not a file handle). If we say
> it does apply to all hard links, and a delegation is recalled, the client
> will do CLAIM_DELEG_CUR with the name of the other hard link!

The delegation applies to the filehandle and the hardlinked names to that
file.
It is the file.  Maybe the perceived incongruity is with the potential
difference between classic unix and windows NFS servers and clients.
In the unix world, dealing with the filehandle for all of this is
straightfoward.  The server deals with the underlying object/filehandle
when determining delegations because the delegation covers the
file/filedata.
THe client deals with the filehandle and name because it is the same file
and the filedata cache is managed as one object at the client.

We have dealt with these issues in the Solaris implementation and don't
find them burdensome.

Spencer

> 
> I still don't think the race you describe would happen often enough (if
> ever) in real life to warrant much attention. Dealing with the race
involves
> checking for existing delegations on CLAIM_NULL. That's pretty expensive!
> Since the race condition you describe would be extremely rare, I think the
> cost of dealing with it is higher cost because it's a cost paid on every
> OPEN with CLAIM_NULL.
> 
> 
> Peter
> 
> -----Original Message-----
> From: Trond Myklebust [mailto:[email-masked]] 
> Sent: Thursday, March 09, 2006 12:03 PM
> To: Peter Varga
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [nfsv4] Open while client has a Delegation
> 
> 
> On Thu, 2006-03-09 at 11:16 -0500, Peter Varga wrote:
> 
> > If a client can "do what it wants" with OPENs while it has write
> delegation,
> > how is the server supposed to know if it should allow or deny the open?
A
> > subset of OPENs/CLOSEs handled locally by the client could have created
> > conflicting share/access modes that the server is not even aware of! We
> > can't allow this kind of mix where half the OPENs are handled locally,
and
> > the other half go to the server. The way I see it is that if a client
> > doesn't want to handle OPENs locally, then fine, it doesn't need write
> > delegation, and the delegation can be recalled.
> 
> If the client has set up conflicting shares on delegated OPENs then it
> has screwed itself over. Why should the server care at that point?
> 
> > As for hard links, well, one could argue that a client accessing data
from
> > two different file names is similar to two clients accessing the data
from
> > the same filename: the NFS client doesn't know which two files are hard
> > linked (since fileid is an optional attribute), so it has separate data
> > caches for each. In this case, returning it the same delegation will be
> > disastrous when it returns the delegation for the first one, then
failing
> to
> > return the delegation for the second one. If I'm correct about this,
it's
> > clear this client should not have write delegation on any of the file's
> hard
> > links.
> 
> Whole swarthes of POSIX programs would break if we didn't guarantee
> cache consistency between hard linked files.
> 
> Even in the case where fileids are not supported, NFS allows clients to
> assume that files are hard linked if and when their filehandles are
> identical. For that reason, all sane servers that support hard links
> take great pains to ensure that hard linked files have identical
> filehandles.
> 
> > Also, if I'm wrong above, and I may very well be :) , if we _are_ going
to
> > allow OPENs while a write-delegation is in effect, then there's no need
> for
> > CLAIM_DELEG_CUR since the end result will be the same as using
CLAIM_NULL
> > (IF CLAIM_NULL doesn't return the same delegation again). Also in this
> case,
> > the server will be forced to scan for existing delegations on every
> > CLAIM_NULL... which would adversely affect its performance.
> 
> Yes. Performance is an issue there, so clients should definitely _try_
> to avoid CLAIM_NULL when they hold a delegation, but servers should also
> be prepared to tolerate the odd race. The cost of revoking a delegation
> is much higher than dealing with the race.
> 
> Cheers,
>   Trond
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 9 Mar 2006 12:38:36 -0600

> knows which files are hard-links, it does not need to send OPEN for the

Mmm, if the client's API/construction actually does a LOOKUP on the file
prior to the OPEN.  It seems as though it would be in the client's best
interest to avoid such LOOKUPs if possible (reduction in workload).

So based on your other recent email and my response to that and this one,
let's call this thread complete.

Spencer

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 Mar 2006 14:10:13 -0500

> knows which files are hard-links, it does not need to send OPEN for the

Actually I'd assumed that the only link that the delegation convers is
the one that was originally opened under.

So if /foo and /bar are hardlinks to the same file, and you do an

	OPEN("/foo")

and get a delegation, and then someone else does

	REMOVE("/bar")

then the server is not required to recall the delegation.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Mar 2006 14:37:39 -0500

> then the server is not required to recall the delegation.

REMOVE("/bar") will change the numlinks field, time_metadata and the
change attribute on the file, all of which may be cached by holders of
delegations. The server is required to recall the delegation in those
circumstances.

Cheers,
  Trond

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 09 Mar 2006 14:45:35 -0500

> then the server is not required to recall the delegation.

the linux server uses a per-inode list to bookeep delegations (and leases) so, 
the linux server does (properly) treat hardlinks as the same file.

-->Andy