Mount and unmount

The XDSM standard implicitly assumes that there is a single mount, pre-unmount and unmount event per file system. In GPFS, a separate mount event is generated by each mount operation on each node. Similarly, if the pre-unmount and unmount events are enabled, they are generated by each unmount operation on each node. Thus, there may be multiple such events for the same file system.

To provide additional information to the DM application, the mode field in the respective event message structures (me_mode for mount, and ne_mode for pre-unmount and unmount) has a new flag, DM_LOCAL_MOUNT, which is not defined in the standard. When the flag is set, the mount or unmount operation is local to the session node. In addition, the new field ev_nodeid in the header of the event message can be used to identify the source node where the mount or unmount operation was invoked. The identification is the GPFS cluster data node number, which is attribute node_number in the mmsdrfs2 file for a PSSP node or mmsdrfs file for any other type of node.

The mount event is sent to multiple sessions that have a disposition for it. If there is no disposition for the mount event, the mount operation fails with an EIO error.

There is no practical way to designate the last unmount, since there is no serialization of all mount and unmount operations of each file system. Receiving an unmount event with the value 0 in the ne_retcode field is no indication that there will be no further events from the file system.

An unmount initiated internally by the GPFS daemon, due to file system forced unmount or daemon shutdown, will not generate any events. Consequently, there need not be a match between the number of mount events and the number of pre-unmount or unmount events for a given file system.

The dmapiMountTimeout attribute on the mmchconfig command enables blocking the mount operation for a limited time until some session has set the mount disposition. This helps GPFS and the DM application synchronize during initialization. See GPFS configuration attributes for DMAPI and Initializing the Data Management application.

Mount events are enqueued on the session queue ahead of any other events. This gives mount events a higher priority, which improves the response time for mount events when the queue is very busy.

If the DM_UNMOUNT_FORCE flag is set in the pre-unmount event message, the response of the DM application to the pre-unmount event is ignored, and the forced unmount proceeds. If the DM_LOCAL_MOUNT flag is also set, the forced unmount will result in the loss of all access rights of the given file system that are associated with any local session.

If the unmount is not forced (the DM_UNMOUNT_FORCE flag is not set), and the DM_LOCAL_MOUNT flag is set, the DM application is expected to release all access rights on files of the given file system associated with any local session. If any access rights remain held after the DM_RESP_CONTINUE response is given, the unmount will fail with EBUSY. This is because access rights render the file system busy, similar to other locks on files.

The function dm_get_mountinfo can be called from any node, even if the file system is not mounted on that node. The dm_mount_event structure returned by the dm_get_mountinfo function provides the following enhanced information. The me_mode field contains two new flags, DM_LOCAL_MOUNT and DM_REMOTE_MOUNT. At least one of the two flags is always set. When both flags are set simultaneously, it is an indication that the file system is mounted on the local node, as well as one or more other (remote) nodes. When only DM_LOCAL_MOUNT is set, it is an indication that the file system is mounted on the local node but not on any other node. When only DM_REMOTE_MOUNT is set, it is an indication that the file system is mounted on some remote node, but not on the local node.

In the latter case (only DM_REMOTE_MOUNT is set), the fields me_roothandle and me_handle2 (the mount point handle) in the dm_mount_event structure are set to DM_INVALID_HANDLE. Also in this case, the me_name1 field (the mount point path) is taken from the stanza in the file /etc/filesystems on one of the remote nodes (with the use of GPFS cluster data, the stanzas on all nodes are identical).

The enhanced information provided by the dm_get_mountinfo function can be useful during the processing of mount and pre-unmount events. For example, before responding to a mount event from a remote (non-session) node, dm_get_mountinfo could be invoked to find out whether the file system is already mounted locally at the session node, and if not, initiate a local mount. On receiving a pre-unmount event from the local session node, it is possible to find out whether the file system is still mounted elsewhere, and if so, fail the local unmount or delay the response until after all remote nodes have unmounted the file system.