検索

このコンテンツは選択した言語では利用できません。

6.2. Known Issues

download PDF
  • 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.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.