길 tl; dr
다이어그램은 본질적으로 정확합니다.
/dev/<device> 파일들
귀하의 질문에 대답하는 가장 기본적인 방법은 /dev/<device>파일이 무엇인지 생각 합니다. 하드 디스크가 있다고 가정하십시오. 이 하드 디스크에는 MBR 기반 파티션 테이블이 있으며 두 개의 파티션이 있습니다. 하나는 ext4로 포맷되어 있고 다른 하나는 LVM으로 설정되어 있습니다. 이 답변은 온더 플라이 장치 파일 생성에 대해 이야기하며, 이는 Linux 커널을 사용하고 있음을 의미합니다. 상황이 조금 다릅니다다른 Unices .
이 하드 디스크를 꽂거나 시스템이 부팅 할 때이를 감지하면 /dev디렉토리 에 장치 파일이 생성됩니다 ( 일반적으로 /dev/sd*또는/dev/hd* (드라이브를 연결하는 데 사용되는 컨트롤러에 따라 다름) . *는 a 편지. 장치 파일의 바이트는 기본적으로 실제 디스크의 바이트에 선형으로 매핑됩니다. 도구를 사용하여 장치 파일의 시작 부분에 쓰는 경우 해당 데이터도 실제 디스크의 실제 시작 부분에 기록됩니다.
이제 시스템은 MBR 및 GPT와 같은 파티션 테이블도 이해합니다. 초기 장치 파일이 작성되면 파티션 테이블이 있는지 판별하기 위해 읽습니다. 그럴 경우 이러한 파티션을 나타내는 장치 파일이 생성됩니다. 따라서 원래 장치 파일이 호출되었다고 가정하면 , 장치 (두 번째 LVM 파티션을 나타냄) 뿐만 아니라 /dev/sda장치 파일 /dev/sda1(첫 번째, ext4 형식 파티션을 /dev/sda2나타냄)이 생성됩니다. 이들은 전체 드라이브와 같은 방식으로 각 파티션에 선형으로 매핑됩니다. 즉, 예를 들어 도구를 사용 의 시작 부분에 쓰면/dev/sda2 쓴 경우 데이터는 물리적으로 두 번째 파티션 시작 부분에 기록됩니다 실제로 중간입니다. 전체 디스크의 두 번째 파티션이 시작되기 때문입니다.
블록 및 섹터
이것은 블록과 섹터에 관해 이야기하기에 편리한 시간입니다. 이것은 물리적 디스크의 공간을 측정하는 것입니다. 섹터는 하드 드라이브의 물리적 영역입니다. 최신 하드 드라이브에서는 일반적으로 512 바이트-4KB입니다. 블록은 측정 단위이며 거의 항상 8KB입니다. 누군가 블록 읽기 및 쓰기에 대해 이야기 할 때, 이는 각 데이터 바이트를 개별적으로 읽는 대신 8KB 단위로 데이터를 읽고 씁니다.
파일 시스템과 아이 노드
다음은 파일 시스템과 inode입니다. 파일 시스템은 상당히 간단한 개념입니다. 파일 시스템이있는 영역의 시작 부분 (이 영역은 일반적으로 파티션 임)에는 파일 시스템에 대한 많은 정보가 있습니다. 이 헤더 (슈퍼 블록이라고도 함)는 먼저 파일 시스템을 읽는 데 사용해야하는 파일 시스템 드라이버를 결정하는 데 사용되며 선택한 파일 시스템 드라이버가 파일을 읽는 데 사용합니다. 물론 이것은 간단하지만 기본적으로 디렉토리 트리와 inode 목록과 같은 두 가지 (fs 유형에 따라 디스크에 두 개의 개별 데이터 구조로 저장되거나 저장되지 않을 수 있음)를 저장합니다. 디렉토리 트리는 당신이 할 때 보이는 것입니다ls 또는tree. 디렉토리 트리는 어떤 파일과 디렉토리가 다른 디렉토리의 자식인지를 나타냅니다. 파일 / 디렉토리 부모-자식 관계는 우리가 아는 것처럼 UNIX 디렉토리 트리를 형성합니다.
그러나 디렉토리 트리에는 이름 만 포함됩니다. 이러한 이름은 추가적으로 inode 번호와 관련이 있습니다. inode 번호에는 파일 조각이 실제로 디스크에 저장되는 위치와 같은 정보가 포함됩니다. inode 자체는 단순히 이름이없는 "파일"입니다. inode는 디렉토리 트리를 통해 이름과 연결됩니다. 수퍼 블록, Inode, Dentry 및 파일이란 무엇입니까?를 참조하십시오 .
지금까지 /dev/sd*파일에 대한 설명 은 하드 드라이브에, /dev/sd*#파일은 파티션 번호 #에 /dev/sd*있습니다. 파일 시스템은 디렉토리 트리를 추적하는 디스크의 데이터 구조입니다. 일반적으로 파티션 ( /dev/sd*#)에 보관됩니다 . 파일 시스템은 inode를 포함합니다. inode는 해당 파일과 관련된 데이터와 함께 파일을 나타내는 숫자입니다 (디렉토리 트리에서 파일 이름 및 위치 제외).
파일 시스템은 일반적으로 블록 단위로 데이터를 추적한다는 점은 주목할 가치가 있습니다. 일반적으로 디렉토리 트리 및 inode 목록은 바이트가 아닌 블록으로 저장되며 inode는 바이트가 아닌 디스크의 블록을 가리 킵니다. (파일 시스템이 전체 블록을 할당했지만 파일의 마지막 부분에 대해 전체 블록을 사용할 필요가 없기 때문에 파일이 일반적으로 공간의 절반을 낭비하는 문제가 발생할 수 있습니다.)
장치 매퍼
퍼즐의 마지막 조각은 리눅스 커널에서 장치 맵퍼 (로로드) 라는 매우 중요한 모듈입니다 modprobe dm. 장치 매퍼를 사용하면 기본적으로 /dev/mapper디렉토리 에 다른 장치 파일을 만들 수 있습니다 . 그런 다음 해당 장치 파일은 다른 데이터 소스에 매핑되어 프로세스에서 변형 될 수 있습니다. 가장 간단한 예는 파일의 일부를 읽는 것입니다.
파티션 테이블로 완성 된 전체 디스크 이미지가 있다고 가정하십시오. 당신은 이미지에서 파티션 중 하나 떨어져 데이터를 읽을 필요가 있지만, 당신은 얻을 수 없습니다 단지 대신 단일 파티션 이미지, 전체 디스크 이미지이기 때문에, 그 파티션. 해결책은 이미지에서 파티션의 위치를 찾은 다음 디스크 이미지의 해당 부분에 새 장치 파일 매핑을 만드는 것입니다. 다이어그램은 다음과 같습니다.
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
\ /
\ /
\ / <- This is a small section of the image being mapped to
\ / the new device file
\ /
\ /
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
그것을 생각하는 또 다른 방법은 변환 파이프 라인과 같습니다 (커널 내부에서 일어나는 일에 대한 더 정확한 은유입니다). 컨베이어 벨트를 상상해보십시오. 요청, 읽기, 쓰기 등은 장치 매퍼로 작성된 장치 파일에서 컨베이어 벨트의 한쪽 끝에서 시작됩니다. 그런 다음 요청은 장치 매퍼 변환을 통해 소스 파일로 이동합니다. 위의 예에서이 소스 파일은 일반 파일 diskimage.img입니다. 다이어그램은 다음과 같습니다.
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
\ request by moving the requested region reaches the source file, and the data
\ Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
\
\ .-------------------. .--------------------------. .------------------------.
\ | /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
\ .___________________. .___+_____+_____+_____+____. .________________________.
\-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
다이어그램에서 장치 매퍼와 연결된 변환 로직 +에 컨베이어 벨트에서 이동할 때 읽기 요청을 조작하는 도구가 거의 없습니다 .
이제는 다이어그램을 복사하여 LVM에 맞게 수정하고 싶지는 않지만 기본적으로 변환 부분은 바이트 범위를 앞으로 이동시키는 것이 아니라 무엇이든 될 수 있습니다. 이것이 LVM의 작동 방식입니다. LVM 물리적 범위는 디스크에 앉아 데이터의 위치를 추적하는 LVM의 일부입니다. LVM의 파일 시스템처럼 생각하십시오. 컨베이어 벨트 은유에서 실제 익스텐트는 소스 파일 중 하나이며 변환은 LVM이 수행하는 작업으로 논리 볼륨 (컨베이어 벨트에서 가장 왼쪽에있는 항목)의 요청을 디스크의 실제 데이터에 매핑합니다. 말하자면...
나는 LVM 개념에 약간 녹슬었지만 볼륨 그룹 IIRC는 본질적으로 LVM의 디스크와 같습니다. 다시 IIRC, RAID 레벨 등이 볼륨 그룹별로 관리됩니다. 그러면 논리 볼륨은 파티션과 같으며 논리 볼륨은 실제로이를 나타내는 장치 파일이 있습니다. 파일 시스템과 항목을 논리 볼륨에 넣습니다.
장치 매퍼의 멋진 점은 내장 된 논리를 임의로 데이터 스택에 삽입 할 수 있다는 것입니다. 읽고있는 장치 이름을 변경하기 만하면됩니다. 이것이 암호화 된 파티션의 작동 방식 ( 파일 수준에서 작동하는 암호화 체계가 아니라 FUSE를 사용하는 방식)이며 LVM의 작동 방식입니다. 나는 현재 다른 예를 생각할 수는 없지만 장치 매퍼는 꽤 나쁜 것입니다.
논리 블록 주소 지정
나는 이것에 대해 들어 본 적이 없으므로 그것에 대한 정보를 제공 할 수 없습니다. 바라건대 누군가 가이 답변을 가져 와서 편집 할 것입니다.