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

[Chuck Lever <[e-mail]>]

On Sep 23, 2010, at 4:43 PM, James Lentini wrote:

> 
> 
> On Thu, 23 Sep 2010, Chuck Lever wrote:
> 
>> 
>> On Sep 23, 2010, at 10:06 AM, James Lentini wrote:
>> 
>>> 
>>> 
>>> On Wed, 22 Sep 2010, Chuck Lever wrote:
>>> 
>>>> 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.
>>> 
>>> 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.
>> 
>> 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.

That addresses my question, thanks.

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

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.

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