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

Chuck Lever <chuck.lever@oracle.com> Thu, 08 July 2010 15:58 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADCE3A6ADE for <nfsv4@core3.amsl.com>; Thu, 8 Jul 2010 08:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Level:
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+noLbHSm-CJ for <nfsv4@core3.amsl.com>; Thu, 8 Jul 2010 08:58:41 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6BC663A6AD9 for <nfsv4@ietf.org>; Thu, 8 Jul 2010 08:58:41 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o68Fwi1u014145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Thu, 8 Jul 2010 15:58:45 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6810Vfw032513 for <nfsv4@ietf.org>; Thu, 8 Jul 2010 15:58:43 GMT
Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 409878741278604639; Thu, 08 Jul 2010 08:57:19 -0700
Received: from [141.144.6.228] (/141.144.6.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Jul 2010 08:57:18 -0700
Message-ID: <4C35F555.1060604@oracle.com>
Date: Thu, 08 Jul 2010 11:57:09 -0400
From: Chuck Lever <chuck.lever@oracle.com>
Organization: Oracle USA
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: nfsv4@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: acsmt353.oracle.com [141.146.40.153]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4C35F5B3.0221:SCFMA4539814,ss=1,fgs=0
Subject: [nfsv4] [FedFS] proposed ADMIN protocol procedure to enumerate server's NSDB store
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2010 15:58:42 -0000

For discussion during today's FedFS phone call

I.     Description of intent for FEDFS_GET_NSDB_NAMES

The operation will return a list of NSDB information that was previously
sent to the ADMIN server via FEDFS_SET_NSDB_PARAMS.  One list entry is
returned for each NSDB.  Each list entry is a FedFsNsdbName.

A maxcount field is used to manage the amount of information that is
returned in a single RPC.  To obtain the entire NSDB list stored on an
ADMIN server, clients must potentially send multiple
FEDFS_GET_NSDB_NAMES requests.  A cookie/verifier pair is used as a
cursor to iterate over the NSDB list.

Such a procedure can be used to check for stale NSDB entries or
misspellings, or to generate a menu of NSDB names in a graphical ADMIN
client (ie for browsing the NSDB list on a server).


II.     Proposed new data types, based on draft 05

    enum FedFsStatus {
       ...
     FEDFS_ERR_NSDB_PARAMS       = 24,
     FEDFS_ERR_NSDB_NOT_SAME     = 25,
     FEDFS_ERR_NSDB_TOO_SMALL    = 26
    };

    typedef opaque                   FedFsVerifier[8];

    struct FedFsGetNsdbNamesArgs {
            FedFsVerifier            verifier;
            unsigned int             cookie;
            unsigned int             maxcount;
    };

    struct FedFsGetNsdbNamesResOk {
            FedFsVerifier            verifier;
            unsigned int             cookie;
            FedFsNsdbName            names<>;
    };

    struct FedFsGetNsdbNamesResTS {
            FedFsVerifier            verifier;
            unsigned int             cookie;
            unsigned int             maxcount;
    };

    union FedFsGetNsdbNamesRes switch (FedFsStatus status) {
     case FEDFS_OK:
            FedFsGetNsdbNamesResOk   resok;
     case FEDFS_ERR_NSDB_TOO_SMALL:
            FedFsGetNsdbNamesResTS   restoosmall;
     default:
            void;
    };

    FedFsGetNsdbNamesRes FEDFS_GET_NSDB_NAMES(
                 FedFsGetNsdbNamesArgs) = 10;


III.     Proposed new language, based on draft 05 and RFC 5661

3.     Error Values

      ...

    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.

    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

5.10.  FEDFS_GET_NSDB_NAMES

    This operation retrieves a partial or whole list of NSDBs that are
    on record with this server.  The server's NSDB list includes NSDBs
    that were previously registered with this ADMIN server via the
    FEDFS_SET_NSDB_PARAMS operation.

    This operation returns only the FedFsNsdbName of each registered
    NSDB.  Clients can retrieve other information related to any of
    the returned NSDBs by subsequently issuing FEDFS_GET_NSDB_PARAMS
    requests for interesting NSDBs.  Viewing the list of on-record
    NSDBs MAY be a less privileged operation than viewing NSDB
    connection parameters returned by FEDFS_GET_NSDB_PARAMS.

    The arguments contain a cookie value that represents where the
    FEDFS_GET_NSDB_NAMES operation should start in the NSDB list.  For
    the initial FEDFS_GET_NSDB_NAMES request, both the cookie value and
    the verifier MUST be set to zero to start reading at the beginning
    of the server's NSDB list.  For subsequent FEDFS_GET_NSDB_NAMES
    requests, the client specifies the cookie and verifier values
    returned by the server from a previous FEDFS_GET_NSDB_NAMES request.

    The cookie value is meaningful only to the server, which uses it
    as a cursor for its NSDB name list.  The cookie value may be cached
    by the client, but the client MUST treat cookie values as entirely
    opaque.  Ideally, the cookie value SHOULD NOT change if the NSDB list
    is modified, since the client may be caching these values.

    The server uses the verifier field to validate the cookie value. On
    subsequent FEDFS_GET_NSDB_NAMES requests, the verifier field in the
    request's arguments must match the verifier returned by the
    FEDFS_GET_NSDB_NAMES request in which the cookie was acquired.  If
    the server determines that the verifier is no longer valid, the error
    FEDFS_ERR_NSDB_NOT_SAME MUST be returned.  To continue reading the
    list, the client must issue a fresh initial FEDFS_GET_NSDB_NAMES
    request, as described above.

    The verifier may be used by the ADMIN server to help manage cookie
    values that may become stale.  It should be a rare occurrence that a
    server is unable to continue properly reading a directory with the
    provided cookie/verifier pair.  The server SHOULD make every effort
    to avoid this condition since the client might be unable to properly
    handle this type of failure.

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

    When there are no more NSDB names to return, the server sets the
    cookie and verifier reply fields to zero.  If the ADMIN server's NSDB
    list is empty on the initial FEDFS_GET_NSDB_NAMES request, the server
    MUST return an empty names list and set the cookie and verifier reply
    fields to zero.

    On success, this operation returns FEDFS_OK, a list of
    FedFsNsdbNames, and a cookie/verifier pair that the client can use
    to retrieve the next list entries.

    On failure, an error value indicating the type of error is returned.
    The operation MAY return FEDFS_ERR_ACCESS if the operation's
    associated user does not have sufficient permissions to view NSDB
    names.

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