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

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

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!

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:11:27 -0600

> 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