Data locality restore
- WADFG is set by mmchattr or the policy.
- Default WAD or WAD is set by policy and the data ingesting node.
If the file is set with WADFG, the locality complies with WADFG independent of where the data is ingested. If the file is not set with WADFG, the locality is decided according to the WAD and data-ingesting node. Also, data locality configurations are the required configurations. If there are no disks available to comply with the configured data locality, the IBM Spectrum Scale™ FPO stores the data in other disks.
The data locality might be broken if there are mmrestripefs -r and mmrestripefile after disk failure or node failure. If your applications need data locality for good performance, restore the data locality after node failure or disk failure.
Data locality impacted from down disks
All disks in a node must be configured as the same failure or locality group. After a disk is non functional, mmrestripefs -r from auto recovery suspends the disk and restripes the data on the non functional disks onto other disks in the same locality group. The data locality is not broken because the data from local disks is still in that node. If you do not have other disks available in the same locality group, mmrestripefs –r from auto recovery restripes the data on the non functional disks onto other nodes, breaking the data locality for the applications running over that node.
Data locality impacted from the non functional nodes
If a non functional node does not have NSD disks in the file system, the data locality is not impacted. If the non functional node has NSD disks in the file system and the node is not recovered within dataDiskWaitTimeForRecovery (if all down disks are dataOnly disks) and metadataDiskWaitTimeForRecovery (if there is meta data NSD disk down), auto recovery suspends the disks and performs restripefs -r. All disks from the non functional nodes are not available for write and the data from the non functional disks is restriped onto other nodes. Therefore, the data locality is broken on the non functional nodes.
Data locality impacted from unintended mmrestripefile -b or mmrestripefs -b
If the file is not set with WADFG (by policy or by mmchattr), both mmrestripefile -b and mmrestripefs -b might break the data locality.
Data Locality impacted from unintended mmrestripefile -l
If the file is not set with WADFG (by policy or by mmchattr), mmrestripefs -l might break the data locality. The node running mmrestripefile -l is considered as the data writing node and all first replica of data is stored in the data writing node for an FPO-enabled storage pool.
The following sections describe the steps to check if your data locality is broken and how fix it if needed.