Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
4.14. The GFS2 Withdraw Function
The GFS2 withdraw function is a data integrity feature of GFS2 file systems in a cluster. If the GFS2 kernel module detects an inconsistency in a GFS2 file system following an I/O operation, the file system becomes unavailable to the cluster. The I/O operation stops and the system waits for further I/O operations to stop with an error, preventing further damage. When this occurs, you can stop any other services or applications manually, after which you can reboot and remount the GFS2 file system to replay the journals. If the problem persists, you can unmount the file system from all nodes in the cluster and perform file system recovery with the
fsck.gfs2command. The GFS withdraw function is less severe than a kernel panic, which would cause another node to fence the node.
If your system is configured with the
gfs2startup script enabled and the GFS2 file system is included in the
/etc/fstabfile, the GFS2 file system will be remounted when you reboot. If the GFS2 file system withdrew because of perceived file system corruption, it is recommended that you run the
fsck.gfs2command before remounting the file system. In this case, in order to prevent your file system from remounting at boot time, you can perform the following procedure:
- Temporarily disable the startup script on the affected node with the following command:
chkconfig gfs2 off
- Reboot the affected node, starting the cluster software. The GFS2 file system will not be mounted.
- Unmount the file system from every node in the cluster.
- Run the
fsck.gfs2on the file system from one node only to ensure there is no file system corruption.
- Re-enable the startup script on the affected node by running the following command:
chkconfig gfs2 on
- Remount the GFS2 file system from all nodes in the cluster.
An example of an inconsistency that would yield a GFS2 withdraw is an incorrect block count. When the GFS kernel deletes a file from a file system, it systematically removes all the data and metadata blocks associated with that file. When it is done, it checks the block count. If the block count is not one (meaning all that is left is the disk inode itself), that indicates a file system inconsistency since the block count did not match the list of blocks found.
You can override the GFS2 withdraw function by mounting the file system with the
-o errors=panicoption specified. When this option is specified, any errors that would normally cause the system to withdraw cause the system to panic instead. This stops the node's cluster communications, which causes the node to be fenced.
Internally, the GFS2 withdraw function works by having the kernel send a message to the
gfs_controlddaemon requesting withdraw. The
gfs_controlddaemon runs the
dmsetupprogram to place the device mapper error target underneath the file system preventing further access to the block device. It then tells the kernel that this has been completed. This is the reason for the GFS2 support requirement to always use a CLVM device under GFS2, since otherwise it is not possible to insert a device mapper target.
The purpose of the device mapper error target is to ensure that all future I/O operations will result in an I/O error that will allow the file system to be unmounted in an orderly fashion. As a result, when the withdraw occurs, it is normal to see a number of I/O errors from the device mapper device reported in the system logs.
Occasionally, the withdraw may fail if it is not possible for the
dmsetupprogram to insert the error target as requested. This can happen if there is a shortage of memory at the point of the withdraw and memory cannot be reclaimed due to the problem that triggered the withdraw in the first place.
A withdraw does not always mean that there is an error in GFS2. Sometimes the withdraw function can be triggered by device I/O errors relating to the underlying block device. It is highly recommended to check the logs to see if that is the case if a withdraw occurs.