[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
- [nfsv4] [FedFS] proposed ADMIN protocol procedure… Chuck Lever
- Re: [nfsv4] [FedFS] proposed ADMIN protocol proce… Everhart, Craig
- Re: [nfsv4] [FedFS] proposed ADMIN protocol proce… Chuck Lever
- Re: [nfsv4] [FedFS] proposed ADMIN protocol proce… Nicolas Williams
- Re: [nfsv4] [FedFS] proposed ADMIN protocol proce… Nicolas Williams
- Re: [nfsv4] [FedFS] proposed ADMIN protocol proce… Chuck Lever
- Re: [nfsv4] [FedFS] proposed ADMIN protocol proce… Nicolas Williams