mmchnsd command

Changes Network Shared Disk (NSD) configuration attributes.

Synopsis

mmchnsd {"DiskDesc[;DiskDesc...]" | -F StanzaFile}

Availability

Available on all IBM Storage Scale editions.

Description

The mmchnsd command serves several purposes. You can use it to:
  • Specify a server list for an NSD that does not have one.
  • Change the NSD server nodes specified in the server list.
  • Delete the server list. The disk must now be SAN-attached to all nodes in the cluster on which the file system will be mounted.
In IBM Storage Scale 5.0.0 or later, you do not need to unmount the file system before changing NSDs.
Note: This feature applies only to non-vdisk NSDs. To enable this feature, you must upgrade all the nodes in the cluster to IBM Storage Scale 5.0.0 or later.
In versions of IBM Storage Scale that are earlier than 5.0.0, you must unmount the file system that contains the NSD that is being changed before you issue the mmchnsd command.
You must follow these rules when you change NSDs:
  • Identify the disks by the NSD names that were given to them by the mmcrnsd command.
  • Explicitly specify values for all NSD servers on the list even if you are only changing one of the values.
  • Connect the NSD to the new nodes prior to issuing the mmchnsd command.
Note: The mmchdisk command does not change the name of the NSD, the NSD servers that are associated with the disk, the storage pool of the disk:
  • The name of the NSD cannot be changed.
  • To change the NSD servers use the mmchnsd command.
  • To change the storage pool use the mmdeldisk and mmadddisk commands.
Prior to GPFS 3.5, the disk information was specified in the form of disk descriptors defined as: 
DiskName:ServerList:
For backward compatibility, the mmchnsd command will still accept the traditional disk descriptors but their use is discouraged.

Parameters

DiskDesc
A descriptor for each NSD to be changed. Each descriptor is separated by a semicolon (;). The entire list must be enclosed in single or double quotation marks. The use of disk descriptors is discouraged.
-F StanzaFile
Specifies a file containing the NSD stanzas for the disks to be changed. NSD stanzas have this format:
%nsd: 
  nsd=NsdName
  servers=ServerList
  usage=DiskUsage
  failureGroup=FailureGroup
  pool=StoragePool
  device=DiskName
  thinDiskType={no | nvme | scsi | auto}

where:

nsd=NsdName
Is the NSD name that was given to the disk by the mmcrnsd command. This clause is mandatory for the mmchnsd command.
servers=ServerList
Is a comma-separated list of NSD server nodes. You can specify up to eight NSD servers in this list. The defined NSD will preferentially use the first server on the list. If the first server is not available, the NSD will use the next available server on the list.

When specifying server nodes for your NSDs, the output of the mmlscluster command lists the host name and IP address combinations recognized by GPFS. The utilization of aliased host names not listed in the mmlscluster command output may produce undesired results.

If you do not define a ServerList, GPFS assumes that the disk is SAN-attached to all nodes in the cluster. If all nodes in the cluster do not have access to the disk, or if the file system to which the disk belongs is to be accessed by other GPFS clusters, you must specify a value for ServerList.

To remove the NSD server list, do not specify a value for ServerList (remove or comment out the servers=ServerList clause of the NSD stanza).

usage=DiskUsage
Specifies the type of data to be stored on the disk. If this clause is specified, the value must match the type of usage already in effect for the disk; mmchnsd cannot be used to change this value.
failureGroup=FailureGroup
Identifies the failure group to which the disk belongs. A failure group identifier can be a simple integer or a topology vector that consists of up to three comma-separated integers. The default is -1, which indicates that the disk has no point of failure in common with any other disk.

GPFS uses this information during data and metadata placement to ensure that no two replicas of the same block can become unavailable due to a single failure. All disks that are attached to the same NSD server or adapter must be placed in the same failure group.

If the file system is configured with data replication, all storage pools must have two failure groups to maintain proper protection of the data. Similarly, if metadata replication is in effect, the system storage pool must have two failure groups.

Disks that belong to storage pools in which write affinity is enabled can use topology vectors to identify failure domains in a shared-nothing cluster. Disks that belong to traditional storage pools must use simple integers to specify the failure group.

If this clause is specified, the value must match the failure group already in effect for the disk; mmchnsd cannot be used to change this value.
pool=StoragePool
Specifies the storage pool to which the disk is to be assigned. If this clause is specified, the value must match the storage pool already in effect for the disk; mmchnsd cannot be used to change this value.

device=DiskName
Is the block device name of the underlying disk device. This clause is ignored by the mmchnsd command.

thinDiskType={no | nvme | scsi | auto}
Specifies the space reclaim disk type:
no
The disk does not support space reclaim. This value is the default.
nvme
The disk TRIM capable NVMe device that supports the mmreclaimspace command.
scsi
The disk is a thin provisioned SCSI disk that supports the mmreclaimspace command.
auto
The type of the disk is either nvme or scsi. IBM Storage Scale will try to detect the actual disk type automatically. To avoid problems, you should replace auto with the correct disk type, nvme or scsi, as soon as you can.
Note: In 5.0.5, the space reclaim auto-detection is enhanced. It is encouraged to use the auto keyword after your cluster is upgraded to 5.0.5.
For more information, see IBM Storage Scale with data reduction storage devices.

Exit status

0
Successful completion.
nonzero
A failure has occurred.

Security

You must have root authority to run the mmchnsd command.

The node on which the command is issued must be able to execute remote shell commands on any other node in the cluster without the use of a password and without producing any extraneous messages. For more information, see Requirements for administering a GPFS file system.

Examples

If the disk gpfs1nsd is currently defined with k145n05 as the first server and k145n07 as the second server, and you want to replace k145n05 with k145n09, create a file ./newNSDstanza that contains:
%nsd: nsd=gpfs1nsd
  servers=k145n09,k148n07
Issue the following command:
# mmchnsd -F ./newNSDstanza
To confirm the changes, issue the following command: 
# mmlsnsd -d gpfs1nsd
A sample output is as follows:
File system  Disk name  NSD servers
---------------------------------------------------------------------
fs2          gpfs1nsd   k145n09.ppd.pok.ibm.com,k145n07.ppd.pok.ibm.com

See also

Location

/usr/lpp/mmfs/bin