 |
Description  |
|
|
TECHNICAL FIELD
The present invention relates generally to a distributed computing environment and more particularly to techniques for providing interoperability of multiple distributed file systems in such an environment.
BACKGROUND OF THE INVENTION
Multiple computers are often interconnected into a local area network (LAN) to enable such computers to exchange information and share resources. A local area network provides a distributed computing environment in which users can access
distributed resources and process applications on multiple computers. A known distributed computing environment, called DCE, has been implemented using software available from the Open Systems Foundation (OSF). In a distributed computing environment, a
group of machines is typically referred to as a "domain." An OSF DCE domain is called a "cell." A DCE cell can be a complex environment involving hundreds of machines in many locations.
As DCE environments become the enterprise solution of choice, many DCE applications may be utilized to provide distributed services such as data sharing, printing services and database access. OSF DCE includes a distributed file system, called
Distributed File Services (DFS), for use in these environments. DFS provides data sharing services by making use of Remote Procedure Calls (RPCs) for data transfer, a Cell Directory Service (CDS) for naming, and a DCE Security Service for authentication
services. In addition to its use of DCE services, DFS itself is rich in features. It provides a uniform global filespace which allows all DFS client users to see the same view of the filespace, and it caches filesystem data at the client for improved
scalability and performance by reducing network traffic to file servers. DFS also supports advisory file locking. One of the features of DFS is the ability to export the operating system's native filesystem. In the case of the AIX operating system,
the native filesystem is the Journaled File System (JFS). In addition, DFS also provides its own physical filesystem, the DCE Local File System (LFS). The DCE LFS provides support for DCE ACLs (Access Control Lists) on files and directories for
securing access to data and advanced data management capabilities such as replication and load balancing.
The OSF DCE DFS was derived from an earlier distributed file system commonly known as AFS. Another known distributed file system was developed by Sun Microsystems and is commonly referred to as Network File System (NFS). Although DCE DFS and
NFS are both distributed file system products, the two products are very different in their data-sharing models and semantics. NFS relies on a peer to peer model between machines while DFS operates within an autonomous administrative unit, namely the
DCE cell. Semantically, NFS is a stateless system implying that the NFS server does not maintain information about the client requests. DFS maintains state on file and directory information in order to provide Unix single-site semantics through the use
of an internal token manager. Administration of a DFS environment is centralized whereby a system administrator can complete the majority of filesystem administration from a single system within the cell. Administration of an NFS environment, on the
other hand, often involves updating information on each NFS client system in the environment.
Given these differences, it has proven difficult to allow such distributed file systems to coexist or interoperate in one environment. However, there are several scenarios where this may be desirable. To this end, current DCE DFS provides
access to the DFS filespace by allowing an NFS server to export the DFS's client's view of the global filespace (which is the Cache Manager's virtual filesystem implementation accessible via a VFS switch) to an NFS client machine. This functionality,
however, is limited to allowing unauthenticated access to the DFS global filespace since NFS is unaware of DCE authentication. As a result, NFS-originated DFS requests are treated as anonymous accesses to the DFS filespace.
There remains a need to provide authenticated access to the DCE DFS filespace from NFS or still other distributed file system products to thereby allow these advanced file systems to coexist and interoperate.
BRIEF SUMMARY OF THE INVENTION
It is thus a primary object of the present invention to enable different distributed file systems to coexist and interoperate within a distributed computing environment domain.
It is a more specific object of the invention to provide authenticated access to the filespace of a distributed file system from file requests that originate from another distributed file system.
It is a further object to map authentication information associated with a file request from a first distributed file system into DCE authentication information suitable for issuing an authenticated request into a second distributed file system.
It is a more specific object of the invention to map at least one credential associated with an incoming client file request into a credential containing authentication information associated with a target distributed file system's authentication
model, and thereafter using the credential to obtain any additional attributes associated with the incoming client file request. A credential is a data structure defining a user.
A more general object of the invention is to provide a gateway between disparate distributed file systems coupled with the notion of extended attribute support for particular file requests.
A still further object of the invention is to isolate distributed file system client(s) from one or more authentication translators registered with a remote attribute interface such that the file system clients do not need to be rewritten in
order to support the translation function. If additional attributes are associated with a particular file request, the remote attribute interface also returns to the file system client appropriate methods to enable the client to obtain those attributes.
According to a preferred embodiment, a distributed computing environment includes a source computer system and a target computer system, each of which has at least one client, one server and a distributed file system. The server associated with
the source computer system is preferably running on a client of the target computer system. The invention provides authenticated access to files stored in the target distributed file system (e.g., DFS) in response to file requests originating from
clients associated with the source distributed file system (e.g., NFS). This is achieved by first mapping credentials associated with incoming client requests from the source distributed file system into credentials containing authentication information
associated with the target distributed file system's authentication model or "paradigm". This is a source-to-target file system authentication translation. The credential containing authentication information associated with the target file system's
authentication model is sometimes referred to as an "enhanced" or "mapped" credential. The source computer system's server (running on the target system's client) then makes the file system request to the target client's virtual filesystem via the VFS
switch with the enhanced credential so that the request looks to the target client as if it were made by an authenticated process.
In certain cases, the client of the target computer system may specify file path variables which allow a pathname to a file to vary depending on the value of the variables. According to the present invention, such a variable may be considered to
be an "attribute" associated with some particular file request. According to the invention, a remote attribute interface isolates one or more target clients from the source-to-target authentication translation and also provides a mechanism for support
of these pathname attributes. An application programming interface (API) enables the target client to extract these attributes for source-originated requests which have authentication mappings. The remote attribute interface further enables additional
authentication translators to be supported, thus allowing multiple source distributed file systems to interoperate with the target distributed file system, all without rewrite of the target client.
The foregoing has outlined some of the more pertinent objects of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial
results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed
Description of the preferred embodiment.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention and the advantages thereof, reference should be made to the following Detailed Description taken in connection with the accompanying drawings in which:
FIG. 1 illustrates a known computer network supporting a distributed file system implementation;
FIG. 2 illustrates a particular distributed computing environment in which the present invention may be implemented;
FIG. 3 is a block diagram the basic functional components of the Translator of the present invention;
FIG. 4 is a flowchart describing the operation of the remote attribute interface of the invention;
FIG. 5 is a block diagram showing the implementation of multiple intermediate authenticators coupled with the dfsrai to thereby facilitate gateways between multiple source file systems and a target file system; and
FIG. 6 is a representation of how the system of FIG. 5 maps an NFS credential to an enhanced credential.
DETAILED DESCRIPTION
A known distributed computing environment (DCE) is illustrated in FIG. 1 and includes two or more nodes A, B and C connected through a communication link or network 3. The network 3 can be a local area network (LAN) or a wide area network (WAN),
the latter comprising a switched or leased teleprocessing (TP) connection to other nodes or to a network of systems operating under a known computer architecture. At any of the nodes A, B or C there may be a processing system 10A, 10B or 10C. Each of
these systems may be a single user system or a multi-user system.
Each of the processing systems is a computer, referred to herein sometimes as a "machine.". For example, each computer may be a RISC System/6000.RTM. (a reduced instruction set or so-called RISC-based workstation) running the AIX.RTM.
(Advanced Interactive Executive) operating system. The AIX.RTM. operating system is compatible at the application interface level with AT&T's UNIX operating system, version 5.2. The various models of the RISC-based computers are described in many
publications of the IBM Corporation, for example, RISC System/6000, 7073 and 7016 POWERstation and POWERserver Hardware Technical Reference, Order No. SA23-2644-00. The AIX operating system is described in AIX Operating System Technical Reference,
published by IBM Corporation, First Edition (November, 1985), and other publications. A detailed description of the design of the UNIX operating system is found in a book by Maurice J. Bach, Design of the Unix Operating System, published by
Prentice-Hall (1986). Alternatively, each computer may be an IBM.RTM. PS/2.RTM. running under the OS/2.RTM. operating system. For more information on the PS/2 line of computers and the OS/2 operating system, the reader is directed to Technical
Reference Manual Personal Systems/2 Model 50, 60 Systems IBM Corporation, Part No. 68x2224 Order Number S68X-2224 and OS/2.0 Technical Library, Programming Guide Volumes 1-3 Version 2.00, Order Nos. 10G6261, 10G6495 and 10G6494.
In one particular implementation, the invention runs on a plurality of IBM RISC System/6000 machines interconnected by IBM's Transmission Control Protocol/Internet Protocol (TCP/IP) architecture. TCP/IP uses as its link level Ethernet, a local
area network (LAN) developed by Xerox Corporation. A simplified description of local area networks may be found in a book by Larry E. Jordan and Bruce Churchill entitled Communications and Networking for the IBM PC, published by Robert J. Brady (a
Prentice-Hall Company)(1983). Although the invention is described in the above-identified context, it should be appreciated that the teachings herein may be implemented using other and different computers interconnected by other networks than the
Ethernet LAN or IBM's TCP/IP.
Returning now back to FIG. 1, each of the processing systems 10 may operate as a "client" or "server," depending on whether it is requesting or supplying services. Each of these systems may be a single user system or a multi-user system with the
ability to use the network 3 to access files located at a remote node in the network. To implement such distributed file services, a local cache 12A, 12B and 12C exists at every node A, B and C. Preferably the local cache is configured on disk or memory
and is adapted to retain data and files that are frequently referenced by the resident applications. For example, if file 5 permanently resides at node A on disk 2A, use of the cache 12A by local processes 13A is carried out locally. However, remote
processes 13B and 13C executing at nodes B and C, respectively, access file 5 through a two step caching scheme using a server cache and a client cache. The server node gets blocks of file 5 from disk 2A and stores them in the server cache 12A. Client
node B goes out over the network and gets blocks of file 5 from the server cache 12A. Client node B stores the blocks of file 5 as it existed in the server cache 12A into the client cache 12B. When the user address space of client B seeks data from any
block of file 5, the client cache 12B is accessed instead of going across the network 3 for each access. Using the client cache 12B to access a remote file 5 can significantly improve the performance since it can reduce network traffic and overhead.
Every file input/output (I/O) operation goes through the cache. These operations include read operations, where the application desires to read data from a file somewhere in the network, and write operations, where the application desires to
write data to a file somewhere in the network.
Although FIG. 1 shows an environment with just several machines, the invention described below is designed to be implemented in any distributed computing environment domain having any number of machines, and these machines may be located in
different geographic locations. For illustrative purposes, the remainder of the detailed discussion is directed to a DCE domain or "cell", although the teachings of the invention are applicable to any distributed computing environment. A representative
DCE cell comprises of a set of connected machines, including at least one server and the DCE clients, which share a common cell name and a namespace. Each cell provides a location independent namespace service called CDS, or Cell Directory Service. The
naming service is used by application servers to store their location and interfaces, known as server bindings. The cell typically includes one or more server machines, such as Security Servers, Cell Directory Service (CDS) Servers and Time Servers,
although most of the machines in the cell are client machines. FIG. 1 thus illustrates a representative DCE cell having the Distributed File System (DFS) service.
A known distributed computing environment is also illustrated in FIG. 2 and includes a source computer system and a target computer system. For illustrative purposes, the source computer system is assumed to have a distributed file system
associated therewith of the NFS type, and the target computer system is assumed to have a distributed file system of the DFS type. Each of source and target computer systems also includes a number of clients and at least one server.
By way of further brief background with respect to FIG. 2, it is known that DFS uses so-called DCE Kerberos-based authentication. A unix "credential" is associated with each "vnode" operation, which holds the local authentication information for
the operation. A credential is a data structure defining a particular user of a multiuser machine (or it may simply describe the machine itself on a non-multiuser system). Typically, from the local operating system's point of view, the credential
includes a user id, a group id, a list of operating system privileges and an authentication identifier known as a PAG (Process Authentication Group). The PAG acts as a tag for associating "tickets" between DFS and the DCE security component. PAGs are
created and managed by the DFS client. A vnode is a data structure used to describe a file, and there is a vector of procedures associated with each vnode.
Generally, there are no AIX services to create or manage PAGs. Instead, when DFS users (so-called "principals") authenticate via dce.sub.-- login, the DCE security component interacts with DFS through a setpag() interface to establish the
PAG/ticket relationship in the process's credential. On filesystem requests, DFS extracts the PAG from the credential structure to establish the DCE principal's authentication for RPC requests to the DFS fileserver.
Also, it is known that the DFS client provides a mechanism for specifying file path variables which allow a pathname to a file to vary depending on the value of the variables. Two such path variables are @sys and @host. The @sys variable
typically has a value indicating a hardware/software combination for a platform. For example, the @sys value for DFS on AIX version 3.2 on the RS/6000 is rs.sub.-- aix32. The @sys variable is commonly used as a switch in filesystem paths to binaries
for particular platforms. For example, /:/local/bin may really be a symbolic link to /:/local/@sys/bin. For AIX, the path, after substitution, would be /:/local/rs.sub.-- aix32/bin. The @host variable is used in the OSF DCE diskless component based on
the DFS protocol.
In NFS, it is known that users are described by user-identifiers (uid's), which are coded as integers. These integers represent user accounts on the NFS client of FIG. 2, for example. In a known operation, the NFS server extracts the
user-identifier from the authentication portion of the NFS client request and uses it to create a unix credential which will be associated with the vnode operation(s) called to satisfy the NFS request. This credential is sufficient to access
locally-mounted filesystems on the server. Thus, in the prior art it has been possible for an NFS client to mount and access DFS although it is not running a DFS client. This scenario, illustrated in FIG. 2, is advantageous in environments where DFS
client software is not available for hardware platforms in the enterprise, such as DOS-based PC's. As seen in FIG. 2, the DFS client runs the NFS server software and makes the DFS filespace available for mounting by adding it to the /etc/exports file.
An entry such as / . . . allows this. NFS clients in turn mount the filesystem the same way they mount other remote filesystems. The NFS client then has access through the path /dfs. True DFS clients have access to the same information through the
path /.:/fs.
In the scenario of FIG. 2, however, NFS clients do not have the ability to be DCE-authenticated and therefore any access they gain to the DFS server will be as un-authenticated users. This is because in the NFS authentication model, the PAG
field within a credential is blank. Thus, in certain circumstances (e.g., where there is an Access Control List set to protect the DFS filespace) NFS clients wishing to gain access to the DFS filespace will be denied such access. The present invention
allows NFS users authenticated access to DFS so that they may access data with access controls.
FIG. 3 shows a simplified block diagram of the Translator 20 of the present invention, which includes a number of functional components: a kernel portion 22 having an intermediate authenticator 24, an NFS listener 26, and a DFS Remote Attribute
Interface (RAI) 28, and a user portion 30 having a manager 32 for managing intermediate authentication mappings. Preferably, the user portion 30 is reached by logging into the DFS client machine running the Translator either locally or via remote login
facility (telnet, rlogin) to manage the intermediate authentication mappings. The manager 32 performs the following functions--authenticate a DCE principal to be associated with an NFS host/id pair, register NFS/DFS authentication mappings with the
Translator, query registered intermediate authentication mappings, and remove intermediate authentication mappings from the translator. In addition, expired mappings are removed from the Translator periodically. As will be discussed below, the command
to perform these functions is called dfsiauth.
The intermediate authenticator 24 forms the core of the Translator. It maintains the intermediate authentication mappings between NFS and DFS, transforms incoming NFS credentials into suitable DFS credentials, contains the intermediate
authenticator's remote attribute manager for @sys and @host support, and provides system call interfaces to manage the intermediate authentication mappings. This component preferably is implemented as a kernel extension.
The NFS listener 26 (called nfs.sub.-- listener) is a function added to the NFS server path and which examines and intercepts incoming NFS client requests destined for the DFS client filesystem. If the intermediate authenticator is active, this
function is called to examine and possibly transform the NFS credentials to contain authentication information necessary for authenticated DFS access. An external interface is provided by this component for the intermediate authenticator to register its
presence.
The last component of the kernel portion 22 is the DFS Remote Attribute Interface 28 (implemented as dfsrai) which provides an interface for the intermediate authenticator to register its remote attribute manager. Remote attribute managers
provide operations for extracting @sys and @host information. The Cache Manager uses dfsrai to query these values for requests which did not originate on the DFS client machine. When the Cache Manager (i.e. the DFS client) sees that the request
originated from a remote source (i.e. an NFS server), it attempts to obtain a dfsrai handle for the given request. If a handle is returned, then the handle's operations can be called to obtain the @host and @sys values for the request represented by the
handle. The dfsrai component is preferably implemented as part of the kernel extension on AIX which holds the DFS Cache Manager function.
As noted above, in order for the filesystem request to be authenticated, the credential must contain a valid PAG which DFS can use to make DCE-authenticated requests to the DFS fileserver. According to the present invention, a NFS request is
uniquely identified by the NFS client's Internet Protocol (IP) address and the uid in the request, therefore an association is made to map from the remote IP address and remote user id to a PAG (which is later placed in the otherwise blank PAG field in
an NFS server request's credential to create an "enhanced" or mapped credential). This process is sometimes referred to as "intermediate authentication." The Translator acts as an intermediate agent which maps host address/uid pairs for NFS requests to
DCE principals via DFS PAGs. It also provides the manager 32 for managing the mappings, and for preparing a NFS server request's credential with the mapped PAG for passage into the DFS client. In that process, the PAG (created from the remote IP
address and the remote user id) is placed in the blank PAG field to create the enhanced credential.
Further, given that various NFS client platforms would be expected to access the DFS filespace via the NFS translator, support for the @sys variable is also provided and is used to facilitate transparent access to platform-specific binaries in
DFS by NFS clients. To support this, an @sys property is stored along with the PAG in the NFS to DFS mappings of the translator and an API is provided for DFS to extract this property for NFS-originated requests which have mappings. This support adds
significant value to the translator and is now described with respect to FIGS. 4-5.
By way of brief background, the DFS Remote Attribute Interface (dfsrai) provides a mechanism in which a resource manager that produces objects can register itself and a set of methods which can be used to extract attributes associated with the
object. Consumers of objects can then use dfsrai to locate a reference to the resource manager's methods which allows extraction of the object attributes. The consumer gains access to the resource manager's object methods by presenting the object to
the dfsrai. The dfsrai then enumerates through the resource managers which have registered with it presenting the object to each manager. If the object belongs to the resource manager, it indicates so by returning a handle which the dfsrai then returns
back to the object consumer. The handle then allows the object consumer to call the resource manager's methods directly to extract the attributes associated with the object.
This model provides a dynamic mechanism in which consumers of objects can obtain attributes on objects without specific knowledge of the resource manager which created the object. The object attributes preferably are not stored in the dfsrai,
instead the dfsrai effectively acts as a location broker to allow object consumers to find object producers with only the object as the information link. This allows several resource managers to produce similar objects which may differ in internal
content or implementation, but support the same attributes. The object consumer, which is only interested in the attributes, can obtain them without knowing which resource manager is behind the object or what the object looks like internally.
FIG. 4 is a flowchart representing the basic operation of the dfsrai as applied in this invention. As noted above, the intermediate authenticator is the object producer. At step 40, the authenticator responds to NFS server requests and produces
credential structures representing authenticated DCE principals. At step 42, the NFS server then passes the generated credentials through the virtual filesystem switch (VFS) to the DFS client (DFS Cache Manager); thus the DFS Cache Manager is the object
consumer which uses the credentials. The DFS Cache Manager, in particular, is interested in the @sys and @host attributes associated with a particular credential. Thus, at step 44 a test is performed to determine whether any such attributes exist. If
the outcome of the test at step 44 is positive, the method continues at step 46 with the Cache Manager by calling the dfsrai with the credential as input. At step 48, the dfsrai presents the credential to the intermediate authenticator which registered
with the dfsrai (and there may be more than one as will discussed below). At step 50, the intermediate authenticator then provides a handle to the dfsrai, and this handle is returned to the DFS Cache Manager by the dfsrai at step 52. At step 54, the
DFS Cache Manager then calls the operations identified in the handle to get the @host and @sys values for the provided credential. With the credential and attribute values, the DFS Cache Manager then carries out the file request to the DFS server at
step 56. The requested data is returned at step 58.
Use of the remote attribute interface RAI mechanism allows for maximum flexibility and future enhancement of the DFS gateway architecture. By hiding details of the object producer, the modifications to the DFS Cache Manager are minimized since
the Cache Manager does not have to understand the internals of the intermediate authenticator implementation. In addition, the RAI mechanism can be used for other gateways to DFS from other file sharing protocols (besides NFS) such as AFS or Novell
Netware. A Novell Netware to DFS authenticating gateway allows Novell Netware clients to gain authenticated access to files stored in DFS. In such case, a separate intermediate authenticator is provided which registers with the dfsrai and produces
DCE-authenticated credentials from Netware requests. The DFS Cache Manager would then obtain @host and @sys values for the credentials produced by the Netware intermediate authenticator. This enables a new gateway to be implemented without requiring
code changes to the DFS Cache Manager.
This approach is illustrated in the block diagram of FIG. 5. In this figure, there is an NFS client which desires to make a file request over the network 62 to a NFS server 64a. NFS server 64a preferably is running on a target computer having
associated therewith an intermediate authenticator (iauth) routines 66a-n, a DFS client 68a (also referred to a DFS Cache Manager), and the DFS Remote Attribute Interface (dfsrai) 70. As noted above, dfsrai 70 provides the important function of
isolating the DFS clients 68 from the iauth routines 66, and thus, several different iauth routines may be implemented. Thus there may be an iauth routine 66a for the NFS server 64a, another iauth routine 66b for the Netware server 64b, and so on. The
dfsrai 70 provides the interface to allow object consumers (namely DFS clients, such as client 68a) to find producers of objects (namely the iauth routines, such as iauth 66a). According to the invention, one or more of the iauth routines have zero to n
additional attributes associated with each enhanced credential. In the NFS/DFS embodiment, these additional attributes include @sys and @host, although others may be used. Such additional attributes generally provide system architecture dependent
pathnames and thus provide additional information pertaining to the file request. Each iauth routine has a remote manager 72a-n registered with Remote Attribute Interface 70.
Upon receipt of a NFS client file request over the network 62, iauth 66a generates an enhanced credential if a NFS/DFS mapping exists for the NFS client and user id. This enhanced credential (outcred) is passed back to the NFS server 64a which
then issues a filesystem request (which includes the outcred) through the VFS boundary 74 to the DFS client 68a. The Cache Manager receives the file request and determines whether additional information pertinent to the request (e.g., the attributes) is
desired. If so, the Cache Manager sends the outcred to the dfsrai, which as noted above acts as the broker to remote managers. The dfsrai then queries each remote manager 72 to determine whether the enhanced credential was generated by the associated
iauth manager. If the enhanced credential belongs to the queried remote manager, the manager indicates this by returning back to the dfsrai a status and a handle. This handle is then returned from the dfsrai back to the Cache Manager 68a, which uses it
to get the attributes. In particular, the Cache Manager issues the appropriate method to iauth to obtain the @sys value, for example. The value is then returned to the Cache Manager and, along with outcred, used to make the file request to the DFS
server over the network 75.
Referring now to FIG. 6, a representation is shown of how the system of FIG. 5 creates the enhanced credential. As seen in FIG. 6, the NFS credential (or "incred") 80 received from the NFS client is a data structure having a number of elements:
a user identifier, a group identifier, and a PAG field, which is blank. The credential is modified by a mapper function 82 of iauth 66 to create the enhanced or modified credential 84, which includes the PAG 86. The iauth routine 66 supports a map
table 88, which is shown in an exploded view. Map table 88 includes a linked list of map entries, one of which is shown. Each map entry is an object having a number of members: a "next" pointer pointing to the next entry in the linked list, the remote
IP address, the uid, the unique PAG generated from the remote IP address and uid, the @sys and @host variables, if any, and a reference count that maintains the object's existence until the count reaches a predetermined value. The dotted line between
the outcred data structure and the map table reflects that the PAG 86 is used to derive the attributes indirectly from the map table through the operation of the remote attribute manager and dfsrai, as previously described.
A detailed design of the translator and the extended attribute support functionality is set forth below. This implementation is merely exemplary and illustrates the NFS/DFS embodiment, although the basic functionality may be used to enable other
gateways between source and target distributed file systems.
1. Kernel Interface Descriptions
The following sections describe the kernel interfaces for the Translator components. These interfaces form the boundaries between the components and are only intended for use by the Translator Components.
1.1 Intermediate Authenticator Interfaces
1.1.1 NFS/DFS Remote Attribute Manager
These operations provide the support for maintaining the @sys and @host properties stored along with the authentication mappings. The Intermediate Authenticator registers its manager via the DFS Remote Attribute Interface (dfsrai.sub.--
registero()). These operations are called via the table of function pointers in the dfsrai handle structure. The DFS Cache Manager is the caller of these functions.
1.1.1.1 nfsdfsCredToRef
Purpose
Find a remote attribute interface handle for a cred structure
Syntax
int nfsdfsCredToRef(struct dfsrai.sub.-- handle *hint, struct ucred *cred, struct dfsrai.sub.-- handle **ref)
Parameters
______________________________________ hint A hint of which dfsrai handle the cred maps to cred credential structure to find a handle for ref returned handle for the given cred ______________________________________
Description
Map from a cred, to a DFS Remote Attribute Interface handle. If a handle is found, then on return, ref will contain a pointer to the handle. Otherwise, ref will be zero upon return.
Return Value
A zero is always returned.
Notes
1.1.1.2 nfsdfsSysName
Purpose
Returns the @sys value for a given DFS Remote Attribute Interface handle
Syntax
int nfsdfsSysName(struct dfsrai.sub.-- handle *handle, char *namep)
Parameters
______________________________________ handle pointer to a DFS Remote Attribute Interface handle namep address of character array of size DFSRAI.sub.-- MAXNAMELEN to place @ sys value ______________________________________
Description
Return the value of the @sys path name for the given DFS Remote Attribute Interface handle.
Return Value
If successful, this routine returns zero. Otherwise a value of one is retur | | |
