파티션 테이블을 생성하는 단계를 거치지 않고도 원시 블록 장치 위에서 성공적으로 pvcreate를 수행할 수 있는 것으로 보입니다. 그런 다음 볼륨 그룹, 논리 볼륨, 마지막으로 파일 시스템을 생성하고 이를 마운트하고 dd를 통해 테스트할 수 있습니다.
작동하는 것 같지만 온전한 점검이 필요합니다. 이것이 나쁜 생각인가요?
원시 블록 장치 위에 GPT 또는 MBR 파티션 테이블을 어떻게 생성합니까?
사용 중인 파티션 테이블의 종류를 표시하기 위해 parted를 어떻게 사용합니까? 나는 다음을 시도했습니다.
parted, /dev/sdb를 선택하고 인쇄하면 다음을 얻습니다.
오류: /dev/sdb: 인식할 수 없는 디스크 레이블
그러나 드라이브는 현재 사용 중이므로 읽고 쓸 수 있습니다. 파티션 테이블 없이 원시 블록 장치 위에서 LVM을 수행할 때 예상되는 출력입니까? 이견있는 사람?
감사해요!
답변1
LVM 자체가 실제 파티션을 갖는 것에 관심이 없더라도 어쨌든 파티션을 만드는 이유 중 하나는 파티션 프로그램에 "뭔가"가 있다는 것을 알리기 위한 것입니다. 악몽 같은 시나리오는 새로운 시스템 관리자가 서버의 부팅 문제를 진단하고, 파티셔닝 프로그램을 실행하고, 파티셔닝되지 않은 디스크를 확인하고, 드라이브가 손상되었다고 결론을 내리는 것입니다.
LVM 파티션을 생성해도 아무런 단점이 없습니다. 당신은?
답변2
원시 블록 장치에서 PV를 생성할 수 있지만 일반적으로 블록 장치가 사용되는 용도에 대해 혼란을 야기할 수 있으므로 이를 피하려고 합니다. 또한 구성 파일이 누락된 경우 LVM이 사용할 수 있는 일부 자동 검색 루틴이 중단될 수도 있습니다.
다음은 parted를 사용하여 전체 드라이브인 1개의 파티션이 있는 GPT를 생성하고 파티션 플래그를 lvm으로 설정하는 예입니다. mkpart에서는 파일 시스템을 지정해야 하지만 파일 시스템을 생성하지는 않습니다. parted의 오랜 버그인 것 같습니다. 또한 1M의 시작 오프셋은 올바른 정렬을 보장하는 것입니다.
parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
답변3
과거에는 PV에 MS-DOS 디스크 라벨이나 GPT 디스크 라벨을 사용했지만 이제는 메인 블록 장치에서 LVM을 직접 사용하는 것을 선호합니다. 매우 구체적인 사용 사례(예: 부팅 섹터 및 부팅 파티션이 있는 디스크)가 아닌 이상 2개의 디스크 레이블을 사용할 이유가 없습니다.
LVM을 직접 사용하면 다음과 같은 이점이 있습니다.
- 단순성 - 2개의 도구 세트를 사용할 필요가 없습니다.
- 유연성 - pvmove를 사용하여 가동 중지 시간 없이 한 디스크 볼륨에서 다른 디스크 볼륨으로 데이터를 이동할 수 있으며, 스냅샷 및 씬 프로비저닝을 사용할 수 있습니다.
- 볼륨을 생성/크기 조정/삭제했음을 커널에 알리기 위해 partprobe 또는 kpartx를 실행할 필요가 없습니다. 그리고partprobe/kpartx가 실패할 수 있음파티션이 사용 중이고 재부팅해야 할 수도 있는 경우
- MS-DOS 또는 GPT 디스크 드라이브 위에 LVM을 사용하는 것과 비교하여 성능이 더 좋을 수도 있습니다.
- fdisk로 생성된 파티션이 기본 볼륨(예: RAID 배열)의 범위와 정렬되지 않은 경우 잠재적인 정렬 오류를 방지합니다.
답변4
RedHat의 LVM 가이드 섹션 4.2.1에 따르면 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin
그들은 파티션 테이블을 가질 필요가 없다고 말했습니다. 심지어 일부(파티션)만 포함하려는 의도가 아니라면 전체 디스크를 VG(볼륨 그룹)에 사용하는 경우 파티션 테이블을 파괴하라고 제안하기도 합니다.