11.10. 파일 시스템 및 스토리지
LVM writecache의 제한
writecache LVM 캐싱 방법에는 캐시 방법에 없는 다음과 같은 제한 사항이 있습니다.
-
pvmove명령을 사용하는 경우writecache논리 볼륨의 이름을 지정할 수 없습니다. -
씬 풀 또는 VDO와 함께
writecache와 함께 논리 볼륨을 사용할 수 없습니다.
다음 제한 사항은 캐시 방법에도 적용됩니다.
-
캐시 또는
write가 연결된 동안 논리 볼륨의 크기를 조정할 수 없습니다.cache
(JIRA:RHELPLAN-27987, BZ#1798631, BZ#1808012)
XFS 할당량 경고가 너무 자주 트리거됩니다.
할당량 타이머를 사용하면 할당량 경고가 너무 자주 트리거되므로 소프트 할당량을 더 빠르게 적용할 수 있습니다. 이 문제를 해결하려면 소프트 할당량을 사용하지 않으므로 경고가 발생하지 않습니다. 결과적으로 구성된 타임아웃을 고려하여 경고 메시지의 양이 소프트 할당량 제한을 더 이상 적용하지 않습니다.
(BZ#2059262)
LUKS 볼륨을 저장하는 LVM 미러 장치는 종종 응답하지 않는 경우가 있습니다.
LUKS 볼륨을 저장하는 세그먼트 유형의 미러가 있는 미러링 된 LVM 장치는 특정 조건에서 응답하지 않을 수 있습니다. 응답하지 않는 장치는 모든 I/O 작업을 거부합니다.
이 문제를 해결하기 위해 복구 가능한 소프트웨어 정의 스토리지 상단에 LUKS 볼륨을 할당해야 하는 경우 미러 대신 세그먼트 유형 raid1 과 함께 LVM RAID 1 장치를 사용하는 것이 좋습니다.
raid1 세그먼트 유형은 기본 RAID 구성 유형이며 권장 솔루션으로 미러 를 대체합니다.
미러 장치를 raid1 로 변환하려면 미러링된 LVM 장치를 RAID1 장치로 변환을 참조하십시오.
(BZ#1730502)
/boot 파일 시스템을 LVM에 배치할 수 없습니다.
/boot 파일 시스템을 LVM 논리 볼륨에 배치할 수 없습니다. 이 제한은 다음과 같은 이유로 존재합니다.
-
EFI 시스템에서 EFI 시스템 파티션 은 일반적으로
/boot파일 시스템 역할을 합니다. uEFI 표준에는 특정 GPT 파티션 유형과 이 파티션에 대한 특정 파일 시스템 유형이 필요합니다. -
RHEL 8에서는 시스템 부팅 항목에 Boot Loader Specification (BLS)을 사용합니다. 이 사양을 사용하려면 플랫폼 펌웨어에서
/boot파일 시스템을 읽을 수 있어야 합니다. EFI 시스템에서 플랫폼 펌웨어는 uEFI 표준에 정의된/boot구성만 읽을 수 있습니다. - GRUB 2 부트 로더에서 LVM 논리 볼륨에 대한 지원이 불완전합니다. uEFI 및 BLS와 같은 표준으로 인해 기능의 사용 사례가 감소하기 때문에 Red Hat은 지원을 개선하지 않습니다.
Red Hat은 LVM에서 /boot 를 지원하지 않습니다. 대신, Red Hat은 LVM 논리 볼륨에 /boot 파일 시스템이 필요하지 않은 시스템 스냅샷 및 롤백을 관리하는 툴을 제공합니다.
(BZ#1496229)
LVM에서 더 이상 혼합 블록 크기의 볼륨 그룹을 생성할 수 없음
group create 또는 extend 와 같은 LVM 유틸리티를 사용하면 PV(물리적 볼륨)에 다른 논리 블록 크기가 있는 볼륨 그룹(VG)을 더 이상 생성할 수 없습니다. 기본 논리 볼륨(LV)을 다른 블록 크기의 PV로 확장하면 파일 시스템이 마운트되지 않기 때문에 LVM에서 이러한 변경을 채택했습니다.
블록 크기를 혼합하여 VG 생성을 다시 활성화하려면 lvm.conf 파일에서 allow_mixed_block_sizes=1 옵션을 설정합니다.
blk-availability systemd 서비스는 복잡한 장치 스택을 비활성화합니다.
systemd 에서 기본 블록 비활성화 코드는 가상 블록 장치의 복잡한 스택을 항상 올바르게 처리하지는 않습니다. 일부 구성에서는 종료 중에 가상 장치가 제거되지 않을 수 있으므로 오류 메시지가 기록됩니다. 이 문제를 해결하려면 다음 명령을 실행하여 복잡한 블록 장치 스택을 비활성화합니다.
# systemctl enable --now blk-availability.service
결과적으로 종료 중에 복잡한 가상 장치 스택이 올바르게 비활성화되고 오류 메시지가 생성되지 않습니다.
(BZ#2011699)
VDO 드라이버 버그는 저널 블록을 통해 장치가 정지될 수 있습니다.
장치 매퍼 일시 중단 작업을 추적하는 동안 VDO 드라이버의 버그로 인해 일부 저널 블록이 메타데이터 업데이트를 기다리는 것으로 표시됩니다. 일시 중단 호출 이후 업데이트가 이미 적용됩니다.
저널이 동일한 물리 블록으로 다시 래핑되면 블록을 사용할 수 없습니다. 결국 블록을 다시 사용할 수 있을 때까지 모든 쓰기가 중지됩니다. VDO 장치의 growPhysical,growLogical, setWritePolicy 작업에는 일시 중지/재개 주기가 포함되어 있으므로 여러 저널 업데이트 후 장치가 정지됩니다.
LVM 툴 관리 VDO 장치의 pvmove 및 lvchange 작업을 사용하여 VDO 풀 또는 논리 볼륨의 크기를 늘리면 이러한 문제가 발생할 수 있습니다.
해결방법은 일시 중단/재개 주기와 관련된 모든 방식으로 VDO 장치 설정을 변경하고 VDO 장치를 완전히 종료한 다음 다시 시작합니다. 이렇게 하면 잘못된 메모리 내 상태가 지워지고 저널 블록이 재설정됩니다. 결과적으로 장치가 더 이상 고정되지 않고 올바르게 작동합니다.
VDO 볼륨을 시작하는 동안 소프트 잠금으로 인해 시스템이 정지됩니다.
pv_mmu_ops 구조에서 커널 ABI 중단을 수정하기 때문에 커널 버전 4.18.0-425.10.1.el8_7 이 있는 RHEL 8.7 시스템, 즉 RHEL-8.7.0.2-BaseOS는 가상 데이터 최적화 (VDO) 볼륨을 시작하는 동안 소프트 잠금으로 인해 커널 패닉을 중단하거나 발생합니다. 이 문제를 해결하려면 kernel-4.18.0-425.10.1.el8_7 로 부팅하기 전에 활성화된 모든 VDO 볼륨을 비활성화하여 시스템이 중단되지 않거나 4.18.0-425.3.1.el8 인 이전 버전의 커널 다운그레이드를 사용하여 VDO 기능을 유지합니다.
