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

[Nicolas Williams <[e-mail]>]

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?

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

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

Nico
--