SSD+HD 혼합 환경에서 LUKS+LVM+LVM 캐시 조합을 사용하여 복잡한 설정(Debian)을 시도하고 있습니다.
SSD의 파티션(lvmcache 볼륨의 파티션 크기: 20GB)을 LVM 캐시로 사용하려면 해당 파티션을 캐시 역할을 하는 볼륨과 동일한 볼륨 그룹에 추가해야 합니다. 이러한 볼륨은 HD(/home 및 /var/lib/docker)에 위치합니다.
SSD 파티션과 HD 파티션의 블록 크기가 다르기 때문에 이 작업을 안전하게 수행할 수 없다는 것을 깨달을 때까지 대부분의 수동 설치 단계(파티셔닝, 암호화 및 잠금 해제)를 거쳤습니다. 기본적으로 블록 크기는 SSD의 경우 512이고 HD의 경우 4096입니다.
SSD 파티션의 블록 크기를 4096으로 변경하는 방법은 무엇입니까? 디스크에 데이터가 없으므로 필요한 파괴적인 단계를 수행할 수 있습니다.
수명의 관점에서 보면 SSD의 블록 크기가 4096이면 읽기/쓰기 주기가 더 적기 때문에 더 좋을 것 같습니다. 약간의 공간이 손실되었지만 거의 모든 대형 파티션이 하드 드라이브에 있기 때문에 걱정하지 않습니다.
답변1
LVM은 하나의 VG에서 서로 다른 블록 크기의 PV를 혼합하는 것을 허용하지 않기 때문에 블록 크기를 변경하려고 한다고 가정합니다. 로 /etc/lvm/lvm.conf변경하여 이 설정을 변경할 수 있습니다 . 그러나 이렇게 하면 두 개의 PV를 사용하는 논리 볼륨을 생성하지 않도록 해야 합니다. 그렇지 않으면 데이터가 손실됩니다(이것이 LVM이 기본적으로 이를 허용하지 않는 이유입니다). LV가 하나의 PV에 있고 캐시가 두 번째 PV에 있으면 어떻게 될지 모르겠습니다. 혼합 섹터 크기 PV의 데이터 손상은 파일 시스템 수준에서 발생하고 캐싱은 블록 수준에서 발생하기 때문에 작동할 수 있으므로 안전할 수 있지만 위험을 감수하지는 않습니다.allow_mixed_block_sizes1
LUKS/dm-crypt 수준에서 이 문제를 "수정"하고 동일한 4096 섹터 크기로 두 개의 LUKS 장치를 생성할 수도 있습니다(옵션 사용 --sector-size 4096) cryptsetup luksFormat. 그러나 이 경우 전원 장애로 인해 데이터가 손실될 위험이 있습니다. , dm-crypt는 4096개 섹터가 있는 512개 섹터 디스크에서 원자 쓰기를 보장할 수 없습니다(이를 방지하기 위해 전체 LUKS를 생성할 수 있지만 성능과 디스크 공간이 희생됩니다).
아마도 4096 드라이브를 512로 전환할 것입니다(대부분의 NVMe 드라이브가 지원하는 경우). 여기서 성능은 그다지 나쁘지 않을 것입니다.
답변2
mke2fs매뉴얼 페이지 에 따르면 :-b 블록 크기 블록 크기를 바이트 단위로 지정합니다. 유효한 블록 크기 값은 블록당 1024, 2048, 4096바이트입니다. 생략하면 블록 크기는 파일 시스템 크기와 파일 시스템의 용도에 따라 경험적으로 결정됩니다(-T 옵션 참조). block-size 앞에 음수 기호("-")가 오는 경우 mke2fs는 경험적 방법을 사용하여 적절한 블록 크기를 결정하지만 블록 크기를 최소한 block-size 바이트로 제한합니다. 이는 2k의 배수인 블록 크기가 필요한 특정 하드웨어 장치에 유용합니다.
그런 다음 파일 시스템의 블록 크기는 1024 이상(ext2 이상에서)으로 나타납니다. 변경할 수 없는 것은 하드웨어의 블록 크기이며 하드웨어의 동작입니다.