Supplying an invalid version number in cluster.conf as a parameter to the cman_tool command will cause the cluster to stop processing information. To work around this issue, ensure that the version number used is valid.

Under some circumstances, creating cluster mirrors with the '--nosync' option may cause I/O to become extremely slow. Note that this issue only effects I/O immediately after the creation of the mirror, and only when '--nosync' is used. To work around this issue, run the following command after the creating the mirror.

lvchange --refresh <VG>/<LV>

luci will not function with Red Hat Enterprise Linux 5 clusters unless each cluster node has ricci version 0.12.2-14

The sync state of an inactive LVM mirror cannot be determined. Consequently, the primary device of an LVM mirror can only be removed when the mirror is in-sync.

If device-mapper-multipath is used, and the default path failure timeout value (/sys/class/fc_remote_ports/rport-xxx/dev_loss_tmo) is changed, that the timeout value will revert to the default value after a path fails, and later restored. Note that this issue will present the lpfc, qla2xxx, ibmfc or fnic Fibre Channel drivers. To work around this issue the dev_loss_tmo value must be adjusted after each path fail/restore event.

Generally, placing mirror legs on different physical devices improves data availability. The command lvcreate --alloc anywhere does not guarantee placement of data on different physical devices. Consequently, the use of this option is not recommended. If this option is used, the location of the data placement must be manually verified.

The GFS2 fsck program, fsck.gfs2, currently assumes that the gfs2 file system is divided into evenly-spaced segments known as resource groups. This is always the case on file systems formatted by mkfs.gfs2. It will also be the case for most file systems created as GFS (gfs1) and converted to gfs2 format with gfs2_convert. However, if a GFS file system was resized (with gfs_grow) while it was in the GFS format, the resource groups might not be evenly spaced. If the resource groups are not evenly spaced, and the resource groups or the resource groups index (rindex) become damaged, fsck.gfs2 might not function correctly.

There is currently no workaround for this issue. However, if the resource groups are not damaged, avoid this issue by copying the file system contents to a new device with evenly-spaced resource groups. Format the new device as gfs2 with mkfs.gfs2, and copy the contents from the old device to the new device. The new device will have evenly-spaced resource groups.