The GPFS daemon

The GPFS daemon performs all I/O operations and buffer management for GPFS. This includes read-ahead for sequential reads and write-behind for all writes that are not specified as synchronous. I/O operations are protected by GPFS token management, which ensures consistency of data across all nodes in the cluster.

The daemon is a multithreaded process with some threads dedicated to specific functions. Dedicated threads for services requiring priority attention are not used for or blocked by routine work. In addition to managing local I/O, the daemon also communicates with instances of the daemon on other nodes to coordinate configuration changes, recovery, and parallel updates of the same data structures. Specific functions that execute in the daemon include:
  1. Allocation of disk space to new files and newly extended files, which is done in coordination with the file system manager.
  2. Management of directories including creation of new directories, insertion, and removal of entries into existing directories, and searching of directories that require I/O.
  3. Allocation of appropriate locks to protect the integrity of data and metadata. Locks affect data that might be accessed from multiple nodes require interaction with the token management function.
  4. Initiation of actual disk I/O on threads of the daemon.
  5. Management of user security and quotas in conjunction with the file system manager.

The GPFS Network Shared Disk (NSD) component provides a method for cluster-wide disk naming and high-speed access to data for applications running on nodes that do not have direct access to the disks.

The NSDs in your cluster can be physically attached to all nodes or serve their data through an NSD server that provides a virtual connection. You are allowed to specify up to eight NSD servers for each NSD. If one server fails, the next server on the list takes control from the failed node.

For a given NSD, each of its NSD servers must have physical access to the same NSD. However, different servers can serve I/O to different non-intersecting sets of clients. The existing subnet functions in GPFS determine which NSD server should serve a particular GPFS client.

Note: GPFS assumes that nodes within a subnet are connected using high-speed networks. For more information on subnet configuration, see Using public and private IP addresses for GPFS nodes.
GPFS determines whether a node has physical or virtual connectivity to an underlying NSD through a sequence of commands that are invoked from the GPFS daemon. The NSD discovery, occurs at initial GPFS startup and whenever a file system is mounted.
Note: To manually cause this discovery action, use the mmnsddiscover command. For more information, see mmnsddiscover command.
This is the default order of access used during NSD discovery:
  1. Local block device interfaces for SAN, SCSI, IDE, or DASD disks
  2. NSD servers
This order can be changed with the useNSDserver mount option.

You must define NSD servers for the disks. In a SAN configuration where NSD servers are defined, if the physical connection is broken, GPFS dynamically switches to the server nodes and continues to provide data. GPFS falls back to local disk access when the discovered path is repaired. This is the default behavior, and it can be changed with the use NSD server file system mount option.

For more information, see Disk considerations and NSD disk discovery.