DongHyeonkaandClaude Opus 5
2109f726fe
기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만 있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문 종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다. SSOT 결함 둘을 고쳤다. - kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이 「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽 `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다. - virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데 원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다. 기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은 둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더 든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다). 계약을 셋 고쳤다. - kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/** 28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는 것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온 것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 커밋도 28개가 어긋났다). - virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고 재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다. - kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고 넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다. style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져 (실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고, engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고 있었다(Question 기록에서 11.94 → 3.86). verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
9.8 KiB
9.8 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 가 실제로 쓰는 크기는 얼마나 다른가
§199 가 2026-09-10 에 이 호스트에서 읽어 둔 값이 있다. 바닥 이미지 base.qcow2 의 형식은 qcow2 이고, 20GB 로 선언한 게스트 오버레이 둘의 실제 파일은 1.4 GiB 와 665 MiB 였다. 오버레이마다 세 명령을 돌려 형식과 세 크기를 나란히 읽은 값은 아직 없다. 이 물음은 이미지마다 그것을 한 표로 적는 데서 끝나고, 성능 판단은 여기서 하지 않는다.
관계
- /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
- 백엔드가 파일이라는 것은 §187 의
virt-install세 줄과 §199 의ls -l출력이 보여 준다. - 형식과 바닥 이미지의 크기는 §199 가 2026-09-10 에
test-server에서 재 두었다.qemu-img info /var/lib/libvirt/images/base.qcow2가 낸 값은file format: qcow2,virtual size: 3 GiB (3221225472 bytes),disk size: 335 MiB다. - 같은 절의
ls -l /var/lib/libvirt/images/가 선언한 크기와 파일 크기를 나란히 보인다. base.qcow2 : 351404032 (335 MiB) kc-lab-1.qcow2 : 1521025024 (1.4 GiB) — 선언 20GB kc-lab-2.qcow2 : 697499648 (665 MiB) — 선언 20GB 시드 ISO 두 장 : 각 378880 (370 KiB) - §199 는 그 결과를 한 줄로 정리했다. 20GB 씩 둘, 합쳐 40GB 를 선언했지만 실제로는 2.1GB 를 썼다.
- §199 는 두 오버레이가 두 배 넘게 갈린 이유도 함께 적었다. k3s server 가 agent 보다 두 배 이상 쓰는 것은 컨트롤 플레인 바이너리와 SQLite 때문이다. 그래서 오버레이 크기는 이미지 형식이 아니라 그 게스트가 무엇을 도는지를 따라간다.
- §231 은 같은 바닥 이미지에
qemu-img map --output=json을 돌려compressed: True인 구간이 606개이고 전체가 1236개라고 적었다. 3 GiB 가운데 2.01 GiB 가 구멍이고 남은 1010 MiB 를 압축해 324 MiB 가 된다. 배포본 qcow2 는 배포 시점에 이미 zlib 로 압축돼 있어서, 바닥 쪽 차이에는 희소 할당과 압축이 겹쳐 있다. 오버레이에 쌓이는 클러스터는 압축되지 않는다.
가정
- §199 가 목록으로 보인 경로가 지금도 그 가상 머신들이 쓰는 이미지라고 본다. 도메인 정의와 대조한 출력은 없다.
- 오버레이도 바닥과 같은 qcow2 라고 본다. §187 이
backing_store로 만들었다고 적었지만 오버레이에qemu-img info를 돌린 출력은 없다. §232 는 그 출력의backing file:줄이 없으면 바닥 이미지이고 있으면 오버레이라고 적었으므로, 오버레이에 한 번 돌리면 형식과 이 가정이 같은 출력에서 함께 갈린다. - 세 명령을 같은 시점에 돌린다고 본다. 실제 사용량은 게스트가 기록하면서 늘 수 있어서, 시점이 벌어지면 한 표에 서로 다른 시각의 값이 들어간다.
미지수
- 오버레이
kc-lab-1.qcow2와kc-lab-2.qcow2의qemu-img info값. 형식과 virtual size, disk size 를 이미지마다 읽은 기록이 없고, §199 가 읽은 것은 바닥base.qcow2하나다. du -h의 실제 점유량이 §199 의ls -l바이트 수와 얼마나 벌어지는지. 두 명령은 서로 다른 것을 센다.- 엣지 게스트의 이미지. §199 는 엣지를 만들기 전 시점이라 목록에
kc-lab-edge.qcow2가 없다. - 지금 시점의 값. §199 는 2026-09-10 값이고 그 뒤로 오버레이가 얼마나 자랐는지는 재지 않았다. 증가를 볼 수 있는 구간은 그 앞 한 주뿐이다 — §215 가 2026-09-03 에 그린 배치에서
kc-lab-1.qcow2는 264M 이고 일주일 뒤 §199 의 같은 파일이 1.4 GiB 다. 두 값은 어긋난 것이 아니라 다른 날의 것이라고 §211 이 스냅샷 날짜로 못박았다.
제약
- 성능 결론을 여기서 내지 않는다. 형식만으로 일반화하지 말라고 개념 문서가 적었고, 성능은 부하와 지연을 재는 다른 물음들이 받는다.
- 한 시점의 세 값만 적는다. 그 차이가 시간에 따라 어떻게 자라는지는 별도 측정으로 넘긴다.
- qcow2 파일 안이 어떻게 생겼는지는 여기서 다루지 않는다. 매핑표와 클러스터와 refcount 는 §231 이 맡고, 이 물음은 명령이 내놓는 값만 받는다.
- 개념 문서는 형식을 묻는 물음과 세 크기를 묻는 물음을 따로 적었는데 여기서는 하나로 받았다. 형식은 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 인지 아닌지만 세 값의 차이로 판정한다.