[ Pobierz całość w formacie PDF ]

/bin/mount --bind /mnt/gfs2a/home/fred /home/fred
/bin/mount --bind /mnt/gfs2a/home/wilma /home/wilma
;;
stop)
/bin/umount /mnt/gfs2a/home/fred
/bin/umount /mnt/gfs2a/home/wilma
;;
status)
;;
restart)
$0 stop
$0 start
;;
reload)
$0 start
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|status}"
exit 1
esac
exit 0
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.gfs2 command. The GFS withdraw function is less
severe than a kernel panic, which would cause another node to fence the node.
56
Example
If your system is configured with the gfs2 startup script enabled and the GFS2 file system is included in
the /etc/fstab file, 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.gfs2
command 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:
1. Temporarily disable the startup script on the affected node with the following command:
# chkconfig gfs2 off
2. Reboot the affected node, starting the cluster software. The GFS2 file system will not be mounted.
3. Unmount the file system from every node in the cluster.
4. Run the fsck.gfs2 on the file system from one node only to ensure there is no file system
corruption.
5. Re-enable the startup script on the affected node by running the following command:
# chkconfig gfs2 on
6. 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=panic
option 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_controld daemon requesting withdraw. The gfs_controld daemon runs the dmsetup
program 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 dmsetup program 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.
57
Red Hat Enterprise Linux 6 Global File System 2
Chapter 5. Diagnosing and Correcting Problems with GFS2 File
Systems
This chapter provides information about some common GFS2 issues and how to address them.
5.1. GFS2 File System Shows Slow Performance
You may find that your GFS2 file system shows slower performance than an ext3 file system. GFS2
performance may be affected by a number of influences and in certain use cases. Information that
addresses GFS2 performance issues is found throughout this document.
5.2. GFS2 File System Hangs and Requires Reboot of One Node
If your GFS2 file system hangs and does not return commands run against it, but rebooting one specific
node returns the system to normal, this may be indicative of a locking problem or bug. Should this occur,
gather the following data:
The gfs2 lock dump for the file system on each node:
cat /sys/kernel/debug/gfs2/fsname/glocks >glocks.fsname.nodename
The DLM lock dump for the file system on each node: You can get this information with the
dlm_tool:
dlm_tool lockdebug -sv lsname.
In this command, lsname is the lockspace name used by DLM for the file system in question. You can
find this value in the output from the group_tool command.
The output from the sysrq -t command.
The contents of the /var/log/messages file.
Once you have gathered that data, you can open a ticket with Red Hat Support and provide the data you
have collected.
5.3. GFS2 File System Hangs and Requires Reboot of All Nodes
If your GFS2 file system hangs and does not return commands run against it, requiring that you reboot
all nodes in the cluster before using it, check for the following issues.
You may have had a failed fence. GFS2 file systems will freeze to ensure data integrity in the event [ Pobierz całość w formacie PDF ]