Re: [nfsv4] [FedFS] proposed ADMIN protocol procedure to enumerate server's NSDB store

[Chuck Lever <[e-mail]>]

On 07/ 8/10 01:42 PM, Nicolas Williams wrote:
> On Thu, Jul 08, 2010 at 11:57:09AM -0400, Chuck Lever wrote:
>>     union FedFsGetNsdbNamesRes switch (FedFsStatus status) {
>>      case FEDFS_OK:
>>             FedFsGetNsdbNamesResOk   resok;
>>      case FEDFS_ERR_NSDB_TOO_SMALL:
>>             FedFsGetNsdbNamesResTS   restoosmall;
>>      default:
>>             void;
>>     };
>>
>>       ...
>>
>>     FEDFS_ERR_NSDB_PARAMS  The fileserver does not have any connection
>>        parameters on record for the specified NSDB.
>>
>>     FEDFS_ERR_NSDB_NOT_SAME  The cookie/verifier pair passed in a
>>        FEDFS_GET_NSDB_NAMES request is no longer valid.
>
> NOT_SAME seems insufficiently descriptive.  How about
> FEDFS_ERR_NSDB_INVALID_COOKIE?

Following the precedent set by the authors of the ADMIN protocol draft, 
I appropriated NOT_SAME from 5661's READDIR procedure.

>>     FEDFS_ERR_NSDB_TOO_SMALL  The caller specified a maxcount that is
>>        not large enough to hold the next FedFsNsdbName in a
>>        FEDFS_GET_NSDB_NAMES result
>>
>>    ...
>>     The maxcount field is a hint of the maximum number of bytes of NSDB
>>     information that should be returned in the reply.  This value
>>     represents the total length of NSDB names, after XDR encoding, and
>>     not the length of the native format of the NSDB names on the ADMIN
>>     server.  If the server is unable to fit a single name within the
>>     maxcount limit, the error FEDFS_ERR_NSDB_TOO_SMALL MUST be returned.
>>     The number of XDR bytes needed to return the next name MUST be placed
>>     in the reply's maxcount field.  The server also returns a
>>     cookie/verifier pair that is needed to read this value (usually
>>     unchanged from the previous failed FEDFS_GET_NSDB_NAMES request).
>
> Why should one tell the server a max reply size instead of a max number
> of NSDBs whose params to return?

Because there is no limit on the size of a single NSDB name.

> Why shouldn't the server decide how many NSDBs to list in a single RPC
> result instead?

The receiving end (the client) may have limited space to receive NSDB 
name information.