---
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 지연을 재는 물음의 해석 조건으로 넘긴다.