파티션에 직접 상주하는 파일 시스템의 오프셋을 찾는 것은 쉽습니다. 파티션 시작 섹터를 확인하고 섹터 크기를 곱하면 완료됩니다.
파일 시스템이 LVM 내부에 있으면 어떻게 되나요? 매직 넘버, UUID 등과 같은 고유한 기능을 찾기 위해 드라이브를 스캔할 수 있지만 콘텐츠 일치에 의존하지 않는 것을 생각하고 있습니다.
다양한 블록 장치에 대한 보편적인 솔루션이 있습니까? LUKS 컨테이너, dm-integrity 등과 같이 데이터를 문자 그대로 저장하지 않는 것들은 어떻습니까? 블록 장치는 어떤 종류의 계층 구조도 형성하지 않는다고 생각하는데 대답은 '아니오'일 것 같은데요?
답변1
장치 매퍼(LVM 포함)에 의존하는 모든 것은 다음을 실행하여 시스템에 설정된 테이블을 볼 수 있는 장치 매퍼 테이블로 나타납니다.
dmsetup table
루트로.
"간단한" 선형 매핑의 경우 다음과 같이 표시됩니다.
… 0 67108864 linear 8:0 2048
오프셋 2048에서 시작하여 장치 8:0에 매핑된 블록 범위가 있다고 말합니다( lsblk장치 노드와 일치하도록 실행).
일반적으로 LVM LV는 하나 이상의 PV에 여러 범위를 포함할 수 있으므로 오프셋에만 의존할 수 없습니다.
답변2
Stephen Kitt의 답변에서 제안한 대로 실제 장치 매퍼 테이블을 보면 이 작업을 수행할 수 있습니다.
하지만, 이 정보는 장치 매퍼 테이블을 복사하는 것 이외의 다른 목적으로는 쓸모가 없습니다. 왜냐하면 주어진 논리 볼륨이 단일 기본 장치에서 올바른 순서로 연속 블록 영역으로 구성된다는 보장이 없기 때문입니다. RAID 설정에 관계없이 단일 논리 볼륨이 여러 물리 볼륨에 걸쳐 있을 수 있으며 논리 확장 영역 매핑을 기반으로 개별 물리 확장 영역이 인접한 물리 디스크는 물론이고 서로에 대해 "올바른" 순서인지 원격으로 보장할 수도 없습니다. . 구역. 서로.
이는 하나의 물리 볼륨 맨 끝에 처음 16MB가 있는 논리 볼륨을 가질 수 있고, 다른 물리 볼륨에 다음 30GB가 있고, 첫 번째 물리 볼륨에 다음 512MB가 있지만 처음 16MB 전의 논리 볼륨을 가질 수 있음을 의미합니다. 나머지 공간은 세 번째 물리적 볼륨에 있습니다. 파일 시스템 "시작"에 대한 정보로 무엇을 계획하든 적어도 어떤 경우에는 작동하지 않을 것이 거의 보장됩니다.