Subject: [nfsv4] possible minor corrections of federated-fs-admin-05

From: Chuck Lever <[email-masked]>
Date: Wed, 22 Sep 2010 15:48:09 -0400

Hi James-

The last paragraph of Chapter 5 section 3 says:

> If the junction is resolved, the fileserver will indicate the type of resolution that was performed using the FedFsResolveRes's resolve value and include a list of UUIDs for the FSN's FSLs in the FedFsResolveRes's fslUuid array.

I think that language needs to be updated to reflect what is now returned in the result of FEDFS_LOOKUP_JUNCTION.  Most important is that an array of FedFsFsl structures is returned, not an array of fslUuids.  I don't recall seeing this change in the most recent set of diffs, but my memory could be foggy.

Also, we had previously discussed adding a unique error code to the protocol for "procedure not implemented".  Can that be added in the next draft update?

-- 
chuck[dot]lever[at]oracle[dot]com

---

From: James Lentini <[email-masked]>
Date: Thu, 23 Sep 2010 10:06:26 -0400 (EDT)

On Wed, 22 Sep 2010, Chuck Lever wrote:

> I think that language needs to be updated to reflect what is now 
> returned in the result of FEDFS_LOOKUP_JUNCTION.  Most important is 
> that an array of FedFsFsl structures is returned, not an array of 
> fslUuids.  I don't recall seeing this change in the most recent set 
> of diffs, but my memory could be foggy.

Good catch. I will correct that.
 
> Also, we had previously discussed adding a unique error code to the 
> protocol for "procedure not implemented".  Can that be added in the 
> next draft update?

Yes, I can add a FEDFS_ERR_NOTSUPP.

At the start of Section 5, the specification requires fileservers with 
junctions (internal nodes) to implement all of the procedures. The 
procedures are only optional for fileservers that don't support 
junctions (leaf nodes), so only leaf nodes would be allowed to return 
FEDFS_ERR_NOTSUPP.

Which procedures should be allowed to return FEDFS_ERR_NOTSUPP? All of 
the procedures except FEDFS_NULL?

-james

---

From: Chuck Lever <[email-masked]>
Date: Thu, 23 Sep 2010 14:45:47 -0400

> junctions (leaf nodes), so only leaf nodes would be allowed to return 

What about CREATE_REPLICATION and friends?

Can FEDFS_LOOKUP_JUNCTION return NOTSUPP for certain resolveTypes?

---

From: James Lentini <[email-masked]>
Date: Thu, 23 Sep 2010 16:43:24 -0400 (EDT)

> What about CREATE_REPLICATION and friends?

They're currently on the MUST list for internal nodes.

> Can FEDFS_LOOKUP_JUNCTION return NOTSUPP for certain resolveTypes?

Did you have a specific case in mind?

There are several specific error codes, FEDFS_ERR_PATH_TYPE_UNSUPP, 
etc., for reporting LOOKUP errors. Error codes for reporting problems 
with FEDFS_RESOLVE_CACHE requests will be added in the next (-06) 
version of the draft.

Speaking of that, it doesn't appear that anyone proposed 
names/definitions for those errors during the 9/2/10 FedFS meeting (if 
there was a proposal, I apologize for leaving it out of the meeting 
minutes). Do these definitions capture what we agreed to at that 
meeting?

   FEDFS_ERR_NO_CACHE:  The fileserver does not implement an FSN-to-FSL
      cache.

   FEDFS_ERR_UNKOWN_CACHE:  The software receiving the ONC RPC request
      is unaware if the fileserver implements an FSN-to-FSL cache or
      unable to communicate with the FSN-to-FSL cache if it exists.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 23 Sep 2010 16:55:11 -0400

> with FEDFS_RESOLVE_CACHE requests will be added in the next (-06) 

That addresses my question, thanks.

>      unable to communicate with the FSN-to-FSL cache if it exists.

Then FEDFS_OK MUST mean that the file server's cache now matches the results returned by FEDFS_LOOKUP_JUNCTION?

Are these new error codes returned with a FedFsFsl list, or are they returned with no results?

It might make more sense to treat these like the returned ResolveType, instead of using them as the operation's result code, imo.

---

From: James Lentini <[email-masked]>
Date: Thu, 23 Sep 2010 21:18:49 -0400 (EDT)

> On Sep 23, 2010, at 4:43 PM, James Lentini wrote:
<snip> 
> Then FEDFS_OK MUST mean that the file server's cache now matches the 
> results returned by FEDFS_LOOKUP_JUNCTION?

These error codes are for when FEDFS_LOOKUP_JUNCTION is called with 
the FEDFS_RESOLVE_CACHE argument.

For the case you are asking about, when FEDFS_LOOKUP_JUNCTION is 
called with the FEDFS_RESOLVE_NSDB argument, we'll need another error 
code or another result value (as you suggest below).

> returned with no results?

No results.

> It might make more sense to treat these like the returned 
> ResolveType, instead of using them as the operation's result code, 
> imo.

I was thinking of an error code to indicate that the NSDB resolution 
was successful but the FSN-to-FSL cache was not updated 
(FEDFS_NO_CACHE_UPDATE?). Something like this:

    /// struct FedFsLookupResOk {
    ///         FedFsFsn               fsn;
    ///         FedFsFsl               fsl<>;
    /// };
    ///
    /// struct FedFsLookupResReferralVal {
    ///         FedFsNsdbName          targetNsdb;
    ///         unsigned int           ldapResultCode;
    /// };
    ///
    /// union FedFsLookupRes switch (FedFsStatus status) {
    ///  case FEDFS_OK:
    ///  case FEDFS_ERR_NO_CACHE_UPDATE:
    ///         FedFsLookupResOk           resok;
    ///  case FEDFS_ERR_NSDB_LDAP_VAL:
    ///         unsigned int               ldapResultCode;
    ///  case FEDFS_ERR_NSDB_LDAP_REFERRAL:
    ///  case FEDFS_ERR_NSDB_PARAMS_LDAP_REFERRAL:
    ///         FedFsNsdbName              targetNsdb;
    ///  case FEDFS_ERR_NSDB_LDAP_REFERRAL_VAL:
    ///         FedFsLookupResReferralVal  resReferralVal;
    ///  default:
    ///         void;
    /// };

---

From: Chuck Lever <[email-masked]>
Date: Fri, 24 Sep 2010 10:23:47 -0400

> the FEDFS_RESOLVE_CACHE argument.

Ah.  That makes sense now.

>    ///         FedFsLookupResReferralVal  resReferralVal;

Sure, sounds reasonable.