Subject: more Re: [nfsv4] Open/CBGetattr scenario

From: [email-masked]
Date: Wed, 15 Mar 2006 16:55:52 -0500 (EST)

For those who found the handling of CBGetattr/CBRecall and the recent
discussion as confusing as I did, here is what I have currently implemented
and believe works. As well as following the rules of Sec. 9.4.3:

On the server:
	- Saves a clientid when one is encountered in a Compound and uses
	  that clientid to decide whether or not a CBGetattr is required
	  for a subsequent Getattr in the same Compound. (hereafter referred
	  to as an "implied Clientid".) Also, never does a CBGetattr for a
	  Getattr in the same Compound as the Open for which the Write
	  Delegation is being issued.
	  (I don't believe that doing this is required for correct operation,
	   if the client does what is described later, but it seems that it
	   is helpful and harmless to avoid CBGetattr for these cases.)
	- For Remove of any link, Recalls all Delegations for the file. Although
	  CLAIM_PREVIOUS indicates that the Delegation refers to a file and
	  not a link to a file, CLAIM_DELEGATE_CUR uses a name/link. As such,
	  Removal of any link to the file could hamper the client's ability
	  to do an Open/CLAIM_DELEGATE_CUR when attempting to Delegreturn
	  later. As such, the CBRecall needs to be done before Removal of
	  any link and before checking for a conflicting OPEN_DENY is done,
	  since the client may do Open/CLAIM_DELEGATE_CUR prior to the
          Delegreturn.
	  (Thanks Trond, for the "magic bullet" on this one.)
	- For Setattr, recalls any Delegation(s) where the Stateid argument
	  in the Setattr does not refer to the same Clientid as the one
	  for which the Delegation has been issued. This is only done if
	  the Setattr is setting the Size or attribute(s) that affect the
	  file's accessibility, such as ACL, Mode, Owner, Owner_group.
	  It could be argued that ACL,... only need be applied for cases
	  where the resultant access permissions are more restrictive than
	  the ACE in the Delegation Reply, but since the interpretation of
	  that ACE seems to be source of confusion as well, I play it safe
	  and CBRecall for any change of these.
	- When the server does a CBGetattr that fails with
	  NFS4ERR_BAD_HANDLE or doesn't return a Size and/or Change, it
	  assumes that the server's copy of these is current and returns
	  them to the client doing the CBGetattr.

Although using the "implied Clientid" should fix the obvious case observed
at Connectathon, I don't believe it is necesary for correct operation, if
the client does the following:
	- If a server does a CBGetattr where the client doesn't have a
	  Write Delegation for the file OR doesn't yet know the Size and
	  Change attribute for this file, it replies with either
	  NFS4ERR_BAD_HANDLE or NFS_OK, but without the attribute value(s).
	  (The NFS_OK case might not be as safe, since the RFC states that
	   these two attributes are expected to be supported.)
	- If the client has a Write Delegation for a file and does have an
	  established Size, Change for that file, it ignores any Size, Change
	  in the reply to a Getattr. (It would be nice if the client doesn't
	  ask for them after it has established these attributes on the client,
	  but it should be ok, so long as it ignores them in any Getattr
	  reply it receives after establishing them on the client.)
	  It should maintain its own Size for the file, once it has
	  established the size and has the Write Delegation. Ideally done
	  with a Getattr after the Open in the same Compound, but not
	  essential to do so.

When I use the term "established" w.r.t. Size, I simply mean that the client
has received a Size in a Getattr after receiving the Write Delegation and
therefore knows what the size is and that it will only change due to local
operations on this client, until it does a Delegreturn.

Dave Noveck makes a convincing arguemt for not doing CBGetattr for the case
where the file is not allowed to grow by the Write Delegation. However, he
doesn't deal with the possibility of a client delaying truncation and since
the RFC doesn't state this, I've chosen to do CBGetattrs for this case,
limited by the above.

I think this all works? rick

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