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>
110 lines
6.7 KiB
Markdown
110 lines
6.7 KiB
Markdown
---
|
|
id: 77aa0188-5c2b-4f47-bda7-7c66b084968d
|
|
kind: QUESTION
|
|
slug: host-io-scheduler
|
|
title: 이 호스트의 I/O Scheduler 는 무엇인가
|
|
topic: storage-virtualization
|
|
topicName: 스토리지 가상화
|
|
project: virtualization
|
|
status: 초안
|
|
questionStatus: OPEN
|
|
studio: "https://hyeonworks.com/studio/documents/77aa0188-5c2b-4f47-bda7-7c66b084968d/edit"
|
|
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
|
|
source:
|
|
- final/document.md#175-실제-테스트-서버에서-확인할-open-questions-oq-6
|
|
- final/document.md#161-i-o-scheduler
|
|
- final/document.md#162-none
|
|
- final/document.md#163-실제-i-o-scheduler-확인
|
|
- final/document.md#160-blk-mq-multi-queue-block-layer
|
|
---
|
|
|
|
# 이 호스트의 I/O Scheduler 는 무엇인가
|
|
|
|
여러 가상 머신과 호스트 프로세스가 낸 입출력은 같은 호스트 블록 계층으로 들어와 장치로 dispatch 되는데, 그 순서를 정하는 정책이 스케줄러다. 정책이 무엇인지에 따라 부하 구간의 지연을 읽는 조건이 달라진다. 값을 읽는 데는 파일 하나를 보면 되고, 그 파일 이름에 넣을 장치는 이미지 아래를 따라 내려간 물음이 확정한다.
|
|
|
|
## 관계
|
|
|
|
- **VM 아래에 한 번 더 있는 Host block stack — blk-mq · I/O Scheduler · NVMe**
|
|
스케줄러가 그 스택의 어디에서 무엇을 정하는지를 그 개념이 설명한다.
|
|
- **disk image 는 최종적으로 어느 Host block device 위에 있는가**
|
|
그 물음이 확정한 장치 이름을 넣어야 이 확인 명령이 완성된다.
|
|
- **VM1 의 storage 부하가 VM2 의 지연을 실제로 밀어 올리는가**
|
|
여기서 읽은 정책이 그 실험의 결과를 읽는 조건이 된다.
|
|
- **지연 원인을 CPU 로 읽기 전에 storage 계층을 따로 잰다**
|
|
그 기준이 요구하는 스토리지 쪽 조건 가운데 하나를 이 값이 채운다.
|
|
|
|
## 사실
|
|
|
|
§161 은 여러 입출력 요청이 있다고 해서 항상 들어온 순서 그대로 장치에 전달되지는 않고 I/O Scheduler 가 dispatch 정책을 갖는다고 적었다. 대표적으로 볼 수 있는 것으로 셋을 들었다.
|
|
|
|
none
|
|
mq-deadline
|
|
bfq
|
|
|
|
스케줄러마다 목적과 정책이 다르다.
|
|
|
|
§162 는 none 을 복잡한 스케줄링 정책을 최소화해 비교적 직접 장치 쪽으로 dispatch 하는 방향으로 설명했다. NVMe 처럼 장치 자체가 강한 병렬성과 큐 기능을 가진 경우 이런 단순한 정책이 적합할 수 있다. 다만 none 이 블록 계층이 아무 일도 하지 않는다는 상태를 뜻하지는 않는다.
|
|
|
|
§160 은 blk-mq 를 CPU 마다 큐를 두어 여러 CPU 가 병렬로 블록 입출력을 처리하는 구조로 그렸고, 스토리지 처리도 CPU 스케줄링과 완전히 독립된 세계는 아니라고 덧붙였다.
|
|
|
|
§163 은 호스트 확인 명령으로 cat /sys/block/nvme0n1/queue/scheduler 를 들고 예시 출력을 이렇게 보였다.
|
|
|
|
[none] mq-deadline
|
|
|
|
대괄호 안이 현재 선택된 스케줄러다. SATA/SCSI device 라면 cat /sys/block/sda/queue/scheduler 처럼 확인한다.
|
|
|
|
§175 OQ-6 은 같은 파일을 장치 이름을 넣어 읽으라고 했다.
|
|
|
|
§197 은 2026-09-10 에 `df -h /` 를 돌려 이 호스트의 루트가 `/dev/nvme0n1p3` 위에 있는 것을 받았고, §199 는 이미지가 `/var/lib/libvirt/images/` 아래에 있다고 적었다. 명령에 넣을 장치 이름의 후보가 거기서 나온다. 다만 §197 이 낸 이름은 파티션이고 §163 이 경로에 넣어 보인 것은 nvme0n1 과 sda 처럼 장치 쪽 이름이다. 둘 가운데 무엇이 들어가는지는 앞 물음의 lsblk 가 상위 장치를 보인 뒤에 갈린다.
|
|
|
|
이 호스트의 스케줄러 값은 SSOT 에 없다. `/sys/block` 아래의 파일을 읽은 출력이 어디에도 없고, §163 의 nvme0n1 과 sda 는 명령의 모양을 보이려고 든 예시 이름이다.
|
|
|
|
## 가정
|
|
|
|
호스트에 붙어 sysfs 아래의 파일을 읽을 수 있다고 본다.
|
|
|
|
이미지를 담은 장치 이름이 앞 물음에서 확정되어 있다고 보고 그 이름을 명령에 넣는다.
|
|
|
|
읽는 시점의 값이 부하를 걸 때도 같다고 전제하는데, 측정 사이에 누가 값을 바꾸면 이 전제가 깨진다.
|
|
|
|
## 미지수
|
|
|
|
이미지를 담고 있는 장치의 현재 스케줄러가 무엇인지.
|
|
|
|
그 장치에서 선택할 수 있는 목록에 무엇이 들어 있는지. §161 이 든 셋과 같은지도 확인해야 안다.
|
|
|
|
이미지가 놓인 장치가 여럿일 때 장치마다 값이 다른지.
|
|
|
|
## 제약
|
|
|
|
스케줄러를 바꿀지 말지는 이 물음이 정하지 않고, 바꾼 전후를 비교한 측정이 나온 뒤에 결정으로 넘긴다.
|
|
|
|
읽기만 한다. 값을 바꾸면 지금 구성에서 부하가 어떻게 처리되는지 못 본다.
|
|
|
|
§163 의 예시 이름을 이 호스트의 장치 이름으로 옮겨 적지 않고, 앞 물음이 확정한 이름을 넣는다.
|
|
|
|
개념 문서가 명령과 출력 읽는 법을 다 적어 두어서 비어 있는 것은 이 호스트의 값 하나다. 그래서 이 물음이 정할 것은 어느 장치에 그 명령을 돌릴지뿐이고, 그 이름은 이 물음이 스스로 내지 않는다.
|
|
|
|
## 선택지
|
|
|
|
### 1. 이미지를 담은 장치만 읽는다
|
|
|
|
이 물음이 필요한 것은 가상 머신의 입출력이 지나는 장치의 정책 하나여서, 파일 하나를 읽고 대괄호 안의 값을 적으면 끝난다.
|
|
|
|
호스트의 다른 장치가 다른 정책으로 돌고 있어도 그 사실은 안 보인다.
|
|
|
|
### 2. 호스트의 블록 장치를 전부 훑어 값을 함께 적는다
|
|
|
|
장치마다 같은 파일을 읽어 한 표로 만들면 이미지가 놓인 장치의 값이 이 호스트에서 예외인지 아닌지도 함께 보인다. 이미지가 여러 장치에 나뉘어 있는 구성이면 어차피 여러 장치를 읽어야 한다.
|
|
|
|
지금 판단에 쓰이지 않는 장치의 값까지 남게 된다.
|
|
|
|
## 다음 검증
|
|
|
|
1. 이미지 아래를 따라 내려간 물음이 확정한 장치 이름을 가져온다.
|
|
2. 그 이름을 넣어 /sys/block 아래의 queue/scheduler 파일을 읽고 출력을 그대로 적는다 (§175 OQ-6). NVMe 면 cat /sys/block/nvme0n1/queue/scheduler 와 같은 모양이고, SATA/SCSI device 면 cat /sys/block/sda/queue/scheduler 와 같은 모양이다.
|
|
3. 대괄호가 붙은 값을 현재 선택된 스케줄러로 적고, 대괄호 밖의 이름은 선택지로 함께 적는다.
|
|
4. 이미지가 놓인 장치가 여럿이면 장치마다 되풀이한다.
|
|
|
|
닫는 조건 : 장치마다 현재 스케줄러와 선택지가 출력으로 적히면 닫는다. none 이면 §162 의 서술이 이 호스트에 적용된다고 적는다. mq-deadline 이나 bfq 면 dispatch 정책이 개입한다는 사실을 VM1 부하와 VM2 지연을 재는 물음의 해석 조건으로 넘긴다.
|