Provides user-space information to the Cache Manager and File Exporter
Synopsis
dfsbind [-expressprocs number_of_express_daemons]
[-regularprocs number_of_regular_daemons] [-junctionlife
seconds_to_live]
[-prefixlife seconds_to_live] [-notfoundlife seconds_to_live] [-debug] [-help]
Options
-expressprocs number_of_express_daemons
Specifies the number of express processes (user-space threads) allocated to handling requests for security information that do
not require a substantial amount of time. By default, dfsbind uses one express process. Use this option to increase the number of express processes if the local machine encounters a large
number of time-out errors. Specify an integer greater than 0 (zero) to indicate the number of express processes.
-regularprocs number_of_regular_daemons
Specifies the number of regular processes (user-space threads) allocated to handling requests for CDS path name resolution and
requests for security information that may require significant time. By default, dfsbind uses one regular process. Use this option to increase the number of regular processes if the local
machine experiences a large number of time-out errors. Specify an integer greater than 0 (zero) to indicate the number of regular processes.
-junctionlife seconds_to_live
Specifies the length of time for which information cached about Fileset Database machines for a cell remains valid. When dfsbind
retrieves this information from the DFS junction of a cell, it sends the information, along with a "time to live" (TTL), to the Cache Manager. The TTL specifies the length of time for which the
Cache Manager is to consider the information valid. The Cache Manager caches the information and the TTL. It continues to recognize the information as valid until the TTL expires, after which it
asks dfsbind to refresh the information the next time it needs it.
By default, dfsbind assigns a TTL of 24 hours to information about Fileset Database machines. This option can be used to change the TTL that dfsbind assigns to such information. Specify an integer greater than or equal to 30 to indicate the new TTL in seconds.
Note: This option has an effect only on DFS client machines, where it is useful primarily for debugging purposes.
-prefixlife seconds_to_live
Specifies the length of time for which information cached about a path name that is a valid DFS junction name prefix remains valid. When
dfsbind successfully traverses a given path but the path is not a DFS junction name, it sends the Cache Manager the valid path name along with a TTL. The Cache Manager caches the
information and the TTL, continuing to recognize the information as valid until the TTL expires; it then contacts dfsbind to refresh the information the next time it needs it.
By default, dfsbind assigns a TTL of 24 hours to information about path names that are valid DFS junction name prefixes. This option can be used to change the TTL that dfsbind assigns to such information. Specify an integer greater than or equal to 30 to indicate the new TTL in seconds.
Note: This option has an effect only on DFS client machines, where it is useful primarily for debugging purposes.
-notfoundlife seconds_to_live
Specifies the length of time for which information cached about an invalid path name remains valid. When dfsbind cannot traverse
a given path, it sends the Cache Manager the invalid path name along with a TTL. The Cache Manager caches the information and the TTL, considering the information valid until the TTL expires; it
then contacts dfsbind to refresh the information the next time it needs it.
By default, dfsbind assigns a TTL of 1 hour to information about invalid path names. This option can be used to change the TTL that dfsbind assigns to such information. Specify an integer greater than or equal to 30 to indicate the new TTL in seconds.
Note: This option has an effect only on DFS client machines, where it is useful primarily for debugging purposes.
-debug
Provides debugging information about the execution of the command. The primary usage of the information is to ensure that the process is executing properly. If this
option is specified, the process does not automatically place itself in the background once it starts.
-help
Prints the online help for this command. All other valid options specified with this option are ignored.
The help and apropos commands available with all command suites are also available with dfsbind. See the bos help and bos apropos reference pages for examples using these commands.
Description
The dfsbind command starts the dfsbind process, which provides user-space services to the Cache Manager on a DFS client machine or the File
Exporter on a DFS File Server machine. (The Cache Manager and the File Exporter reside in the kernels of their respective machines.) The binary file for the dfsbind command resides in
dcelocal/bin/dfsbind. By default, the process automatically places itself in the background after it starts.
The dfsbind process must be run on all client machines and File Server machines. A machine that runs the Cache Manager (which is initialized by the dfsd command) and the dfsbind process is considered a DFS client machine. A machine that runs the Fileset Server (ftserver process), the File Exporter (which is initialized by the fxd command), and the dfsbind process is considered a DFS File Server machine.
On either type of machine, the dfsbind command is usually added to the proper start-up file (/etc/rc or its equivalent) rather than entered at the command shell prompt. On a client machine, the dfsbind process must be run before the dfsd process in a start-up file; on a File Server machine, it must be run before the fxd process in a start-up file.
On a client machine, the dfsbind process performs the following services:
· It contacts CDS to resolve DCE path names (both local and foreign) that it receives from the Cache Manager. When a user on a client machine requests data that the Cache Manager has not cached, the Cache Manager employs dfsbind to resolve the path name of the data. It sends dfsbind each element of the path name in succession, appending each new element to the preceding elements when it sends it (for example, it first sends /.../element_one, then /.../element_one/element_two, and so on). In turn, dfsbind determines whether each successive path name is valid.
If the path name of the data is valid, it eventually contains a DFS junction from which dfsbind can access information about the Fileset Database machines for the cell in which the data resides. If it encounters a junction for the DFS filespace, dfsbind returns information about the names and network addresses of the Fileset Database machines for the cell to the Cache Manager. (It actually decomposes binding handles to learn this information.)
The Cache Manager uses the information from dfsbind to create an RPC binding that it employs to communicate with a Fileset Location (FL) Server on an appropriate Fileset Database machine. The FL Server examines the FLDB and tells the Cache Manager which File Server machine houses the fileset that contains the data requested by the user.
For each successive path name that it attempts to resolve for the Cache Manager, the dfsbind process returns one of the following error codes to the Cache Manager to indicate the result of the resolution operation:
0 (zero)
Indicates that the path name corresponds to a DFS junction that contains information about the Fileset Database machines in the cell. The process sends information
about the Fileset Database machines to the Cache Manager.
EISDIR
Indicates that the path name is a valid DFS junction name prefix but is not itself a DFS junction. The process returns the valid path name to the Cache Manager.
ENOENT
Indicates that the given path could not be traversed. The process returns the invalid path name to the Cache Manager.
ETIMEDOUT
Indicates that unexpected errors occurred. The process returns only the error code to the Cache Manager.
DCE path name and DFS junction information that the Cache Manager receives from dfsbind is valid for a limited amount of time. The dfsbind process associates a "time to live" (TTL) with all information it sends to the Cache Manager. The TTL defines the amount of time for which the Cache Manager is to consider the information valid. The Cache Manager caches the TTL with the information. Once its TTL has elapsed, the information becomes stale; the Cache Manager contacts dfsbind to refresh the information the next time it needs it.
The dfsbind process associates the following TTLs with the information it passes to the Cache Manager as follows:
- Information about Fileset Database machines (error code 0) receives a TTL of 24 hours by default. (The TTL of such information can be modified with the dfsbind command's -junctionlife option.)
- Information about valid DFS junction name prefixes (error code EISDIR) has a TTL of 24 hours by default. (The TTL of this type of information can be changed with the command's -prefixlife option.)
- Information about invalid path names (error code ENOENT) has a TTL of 1 hour by default. (The TTL of this type of information can be altered with the command's -notfoundlife option.)
For example, when the Cache Manager first needs to access data from a fileset in the local cell, it passes each successive element of the DCE path name of the data to dfsbind. If the path contains a DFS junction name, dfsbind eventually returns information about the local cell's Fileset Database machines, and a TTL that it assigns to the information, to the Cache Manager. The Cache Manager caches the information and the TTL, using the information to contact a Fileset Database machine in the cell. If the Cache Manager needs to access data from a fileset in the local cell before the TTL has elapsed, it uses the cached information to contact a Fileset Database machine in the cell. However, if it needs to access data from a fileset in the local cell after the TTL has elapsed, it again contacts dfsbind to refresh its knowledge of local Fileset Database machines.
· It obtains user authentication information for the kernel RPC Runtime. It communicates with the Security Service of the appropriate cell to obtain authentication information about users of the client machine.
The Cache Manager communicates with the kernel RPC Runtime when it needs to create an RPC binding to a File Server machine on behalf of a user. The kernel RPC Runtime then communicates with dfsbind to obtain authentication information about the user for use in the binding. The dfsbind process obtains the authentication information from the Security Server and sends it back to the kernel RPC Runtime, which packages the information along with the other information from the Cache Manager into the RPC binding and sends it to the appropriate File Server machine.
On a File Server machine, the dfsbind process simply maintains user authentication information required by the File Exporter on the machine. The File Exporter uses this information to ensure that only authenticated users access data from the machine.
The command's -expressprocs and -regularprocs options can be used to change the default number of processes dfsbind runs on a machine as follows:
· The -expressprocs option specifies the number of express processes that dfsbind allocates for the handling of requests that require little time to complete. For example, express processes service requests for information from the local Security Service. The dfsbind process can typically handle these types of requests more quickly than it can those assigned to regular processes.
· The -regularprocs option specifies the number of regular processes that dfsbind allocates for the handling of requests that may require a substantial amount of time to complete. For example, regular processes service requests for the resolution of DCE path names and for information from the Security Service of a foreign cell. The dfsbind process typically requires more time to handle these types of requests than it does to handle requests assigned to express processes.
Employing two types of processes allows dfsbind to function more efficiently. Requests are assigned to processes according to the amount of time they require to complete. Thus, requests with short turnaround times are not queued behind requests with long turnaround times. Increase the number of express and regular daemons on a machine that experiences a large number of time-out (ETIMEDOUT) errors. (Note that both express and regular processes run as threads rather than processes, so neither type of process shows up in the output of the ps command or its equivalent.)
If the -debug option is included with the dfsbind command, the process provides debugging information as it executes. The debugging output is in the form of brief messages reporting the action currently being performed. The messages are useful primarily to ensure that the process is executing properly. If the -debug option is included with the command, the process does not automatically place itself in the background after it starts.
Privilege Required
The issuer must be logged in as root on the local machine.
Examples
The following line, entered in the appropriate initialization file (/etc/rc or its equivalent) on a client or File Server machine, starts the dfsbind
process on the local machine. This line must be included before the line that starts the dfsd or fxd process on a client or File Server machine. The dfsbind process in
the example uses two express processes and two regular processes.
dfsbind -expressprocs 2 -regularprocs 2
Related Information
Commands: dfsd(8dfs)