검색

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

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은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.