7.4 KiB
id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source
| id | kind | slug | title | topic | topicName | project | status | questionStatus | studio | sourceRevision | source | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ae69e2e1-1a3b-4ae3-ae2a-572af07b95d7 | QUESTION | disk-image-format-and-actual-host-usage | 이 disk image 는 qcow2 인가 RAW 인가, 그리고 Guest 가 보는 크기와 Host 가 실제로 쓰는 크기는 얼마나 다른가 | storage-virtualization | 스토리지 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/ae69e2e1-1a3b-4ae3-ae2a-572af07b95d7/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
이 disk image 는 qcow2 인가 RAW 인가, 그리고 Guest 가 보는 크기와 Host 가 실제로 쓰는 크기는 얼마나 다른가
게스트가 100 GB 짜리 디스크를 보고 있어도 호스트에서 그 파일이 차지하는 공간은 훨씬 작을 수 있다. 개념 문서는 그 차이를 예시 숫자로만 들어 두고, 세 명령이 각각 다른 의미의 크기를 보여 준다고 적었다. 이 물음은 이 호스트의 이미지마다 형식과 세 크기를 한 표로 적는 데서 끝난다. 형식과 세 값이 채워지면 저장 공간 계획의 근거가 생기고, 그 뒤의 성능 판단은 여기서 하지 않는다.
관계
- /dev/vda 뒤에 있는 것 — qcow2 · RAW · Host block device 형식이 어디에서 갈리고 각 형식이 무엇을 더 하는지를 그 글이 설명한다.
- Guest 안에서 본 disk 로 backend 를 단정하지 않는다 이 물음이 그 기준의 형식 확인과 용량 확인 항목을 이 호스트에서 채운다.
- 이 호스트의 /dev/vda 는 어떤 backend 에 붙어 있는가 명령을 돌릴 경로를 그 물음이 확정한다.
- disk image 는 최종적으로 어느 Host block device 위에 있는가 같은 경로를 받아 그 파일 아래를 잇는 물음이다.
사실
- 개념 문서는 같은 대상이 호스트에서는 파일 하나이고 게스트에서는 /dev/vda 라는 디스크이며 둘 다 맞다고 놓았다.
- qcow2 는 가상 디스크 크기와 실제 호스트 할당량이 다를 수 있다. 개념 문서가 든 그림은 게스트가 보는 공간 100 GB 에 호스트 실제 할당 3GB 였다.
- 게스트가 데이터를 기록하면서 실제 사용량이 늘 수 있다. 개념 문서는 Virtual 100GB 를 유지한 채 Actual 이 1GB 에서 10GB 로, 다시 40GB 로 가는 예를 보였다.
- 개념 문서는 확인 명령으로 qemu-img info vm1.qcow2 를 들고 virtual size 와 실제 allocation 을 구분해서 봐야 한다고 적었다.
- RAW 는 qcow2 보다 구조가 단순하다. qcow2 는 Copy-on-Write 와 sparse allocation 과 스냅숏 등에 유리하지만 매핑과 메타데이터 처리가 있고, RAW 는 상대적으로 직접적인 offset 대응으로 간다.
- 형식만으로 성능을 가르지 말라고 개념 문서가 못박았다. RAW 는 무조건 빠르고 qcow2 는 무조건 느리다는 일반화를 막고, 실제 성능이 캐시 모드와 스토리지 백엔드와 부하 패턴과 큐 깊이와 스냅숏 체인과 그 아래 파일시스템과 물리 장치에 영향을 받는다고 들었다.
- 개념 문서가 이 확인에 적어 둔 명령은 셋이다. 세 명령이 보여주는 의미가 서로 다를 수 있으므로 비교하라고 했다. 형식과 크기 : qemu-img info 실제 점유량 : du -h 파일 크기 : ls -lh
- 이 호스트의 이미지 형식도 크기도 적힌 기록이 없다.
가정
- 이미지 경로가 앞선 물음에서 확정된다고 본다. 경로가 없으면 세 명령을 어디에 돌릴지 정해지지 않는다.
- 백엔드가 파일이라고 전제한다. 호스트 블록 장치로 나오면 이 물음 자체가 이 호스트에 적용되지 않는다.
- 세 명령을 같은 시점에 돌린다고 본다. 실제 사용량은 게스트가 기록하면서 늘 수 있어서, 시점이 벌어지면 한 표에 서로 다른 시각의 값이 들어간다.
미지수
- 가상 머신마다 디스크 이미지가 qcow2 인지 RAW 인지.
- qemu-img info 가 보여 주는 virtual size 와 disk size 가 각각 얼마인지.
- du -h 의 실제 점유량과 ls -lh 의 파일 크기가 그 값들과 얼마나 벌어져 있는지.
제약
- 성능 결론을 여기서 내지 않는다. 형식만으로 일반화하지 말라고 개념 문서가 적었고, 성능은 부하와 지연을 재는 다른 물음들이 받는다.
- 한 시점의 세 값만 적는다. 그 차이가 시간에 따라 어떻게 자라는지는 별도 측정으로 넘긴다.
- 앞선 물음이 Source 를 확정하기 전에는 이 확인을 시작할 수 없다.
- 개념 문서는 형식을 묻는 물음과 세 크기를 묻는 물음을 따로 적었는데 여기서는 하나로 받았다. 형식은 qemu-img info 출력의 첫 줄이고 세 값을 견주는 일의 전제라 같은 출력으로 함께 닫힌다. 같은 측정으로 닫히는 물음을 두 편으로 두지 않는다.
선택지
1. 이미지마다 세 명령을 이어서 돌리고 한 표로 남긴다
같은 경로에 qemu-img info 와 du -h 와 ls -lh 를 이어서 돌린다. 형식과 virtual size 와 disk size 는 첫 출력에서 읽고 그 옆에 나머지 두 값을 붙이면, 세 값의 차이가 한 행에서 보인다. 세 명령이 붙어 돌아가므로 시점 차이도 거의 없다.
이미지가 많으면 출력이 길어지므로 가상 머신 이름과 경로를 행 머리에 둔다.
2. 형식만 먼저 읽고 크기 비교는 뒤로 미룬다
qemu-img info 한 번이면 file format 이 나오므로 qcow2 인지 RAW 인지가 먼저 갈리고, RAW 로 나오면 확인할 항목이 줄어든다. 개념 문서가 두 물음으로 나눠 적은 모양이 이 순서다.
대신 같은 경로에 두 번 접근하게 되고, 두 시점 사이에 게스트가 기록하면 크기 값이 형식을 읽은 시점의 상태와 어긋난다.
3. 파일시스템 사용량 합계로 대신한다 — 제외
이미지가 놓인 파일시스템을 df -h 로 보면 파일을 하나씩 재지 않아도 전체 점유가 나온다.
그 값에는 이미지가 아닌 파일도 함께 들어가 있어서 이미지 하나가 얼마를 쓰는지 갈라 주지 않는다. 개념 문서가 비교하라고 한 것은 같은 이미지에 대한 세 값이고, 합계로는 virtual size 와의 차이도 나오지 않는다.
다음 검증
- 앞선 물음이 확정한 Source 경로마다 qemu-img info 를 돌려 file format 과 virtual size 와 disk size 를 적는다.
- 같은 경로에 du -h 와 ls -lh 를 돌려 두 값을 나란히 적는다.
- 가상 머신이 여럿이면 이미지마다 한 행으로 한 표에 모으고 세 명령의 출력을 그대로 증거로 둔다.
닫는 조건 : 이미지마다 형식과 세 크기가 한 표로 적히면 닫는다. qcow2 이고 세 값이 벌어져 있으면 개념 문서가 예시로만 든 차이가 이 호스트에서 얼마인지 확정한 것이고, 그 차이가 자라는 모습은 별도 측정으로 넘긴다. RAW 이면 그 갈래가 이 환경이라고 적고 sparse 인지 아닌지만 세 값의 차이로 판정한다.