운영체제 아주 쉬운 세가지 이야기 13주차(하드 디스크 드라이브)

[OS / Disk] 하드 디스크 드라이브(HDD) 한 번에 정리하기

• 디스크는 물리적으로 어떻게 생겼고, 어떤 요소가 시간을 잡아먹는가?
• 랜덤 I/O vs 순차 I/O 성능 차이가 왜 수십~수백 배까지 나는가?
• OS와 디스크는 어떻게 스케줄링해서 I/O 성능을 끌어올리는가?
• 실무에서 “디스크 친화적인 코드”를 짜려면 무엇을 신경 써야 하는가?

---

1. 디스크 인터페이스: “섹터 배열”로 보는 시각

1-1. 디스크는 결국 sector[] 배열이다

• 디스크는 0 ~ n-1까지 번호가 붙은 섹터(sector)들의 배열로 볼 수 있습니다. (보통 512B 단위)
• 클라이언트(파일 시스템 등)는 “k번 섹터 읽어줘/써줘” 식으로 요청합니다.
• 여러 섹터(예: 4KB = 8섹터)를 한 번에 읽고 쓰는 것도 가능하지만, 원자성(atomicity) 보장은 512B 단위만 해줍니다.
  • 4KB 쓰기 중간에 전원 나가면? → 찢어진(torn) write 발생 가능.

1-2. “Unwritten Contract” – 디스크가 암묵적으로 약속하는 것들

공식 인터페이스에 안 써 있지만, 대부분의 HDD는 다음 “암묵적 약속”을 지킵니다.

• 서로 주소가 가까운 블록은 멀리 떨어진 블록보다 접근이 빠르다.
• 연속된 블록을 순차적으로 읽고 쓰는 게 가장 빠르다.

→ 설계/코딩할 때 항상 기억할 한 줄:
“디스크는 연속/근접 I/O를 좋아하고, 랜덤 I/O를 싫어한다.”

---

2. 디스크의 물리 구조: 플래터, 트랙, 섹터, 헤드

2-1. 기본 구성 요소

• Platter : 자기 코팅된 동그란 판 (알루미늄, 유리 등)
• Surface : 플래터 앞/뒷면 각 한 면
• Spindle : 플래터들이 꽂혀 있는 축, 모터가 이 축을 회전시킴
• RPM : 분당 회전수 (보통 7,200 ~ 15,000 RPM)
  • 예: 10,000 RPM → 초당 10,000/60 ≒ 166.7회 회전 → 한 바퀴 ≒ 6ms
• Track : 하나의 서피스 위에 동심원으로 그려진 섹터들의 원
• Head : 각 서피스마다 붙어 있는 읽기/쓰기 헤드
• Arm : 여러 헤드를 같이 붙잡고 트랙 사이를 움직이는 팔

2-2. 디스크 I/O 시간의 세 요소

1. Seek Time (T_seek)
   • 디스크 암이 다른 트랙으로 이동하는 시간
   • 가속 → 최대 속도 → 감속 → settling (정밀 위치 맞추기)
2. Rotational Delay (T_rotation)
   • 원하는 섹터가 헤드 아래로 회전해 올 때까지 기다리는 시간
   • 평균 회전 지연 ≒ ½회전 시간
3. Transfer Time (T_transfer)
   • 섹터들이 실제로 읽히고/쓰이는 시간
   • 보통 “전송률(MB/s)”로 표현

디스크 I/O 공식

TI/O = Tseek + Trotation + Ttransfer

RI/O (I/O rate) = TransferSize / TI/O
  

대부분의 경우 T_seek + T_rotation >> T_transfer 이라서,
“헤드 이동 + 회전 기다리기”가 거의 전부라고 이해하면 편합니다.

---

3. 디스크 디테일: 트랙 스큐, 존, 캐시

3-1. Track Skew – 연속 읽기가 끊기지 않게

• 트랙을 바꾸는 데도 약간의 시간이 걸립니다.
• 그래서 실제 디스크는 트랙의 섹터 시작 위치를 조금씩 밀어서(skew) 배치합니다.
• 그래야 “트랙 경계 넘어가는 연속 읽기”가 끊기지 않고 이어질 수 있음.

3-2. Zoned Bit Recording – 바깥 트랙이 더 크다

• 겉으로는 일정 간격의 트랙처럼 보이지만, 실제로는 바깥쪽 트랙이 안쪽보다 둘레가 길다 → 더 많은 섹터 저장 가능.
• 디스크는 여러 개의 zone으로 나뉘고, 각 zone마다 “트랙당 섹터 수”가 다릅니다.
• 바깥쪽 zone에서 전송률이 더 높게 나오는 이유.

3-3. Disk Cache / Track Buffer

• 디스크 안에는 소용량 메모리(수 MB~수십 MB)가 있습니다.
• 읽기:
  • 어떤 섹터를 읽을 때, 그 트랙 전체를 캐시에 같이 읽어둘 수 있음.
  • 이후 같은 트랙의 다른 섹터 요청이 오면 빠르게(hit) 처리 가능.
• 쓰기:
  • Write-back: 캐시에만 쓰고 “끝났다고 보고” → 빠르지만, 전원 나가면 위험.
  • Write-through: 실제 플래터에 기록된 후에 완료 보고 → 더 안전하지만 느릴 수 있음.

---

4. I/O 성능: 랜덤 vs 순차, 수백 배 차이

4-1. 예시 디스크 스펙

책에서는 두 가지 디스크를 비교합니다.

• Cheetah 15K.5 (고성능 SCSI)
  • RPM: 15,000
  • 평균 seek: 4ms
  • 최대 전송률: 125 MB/s
• Barracuda (대용량 SATA)
  • RPM: 7,200
  • 평균 seek: 9ms
  • 최대 전송률: 105 MB/s

4-2. 랜덤 4KB 읽기 vs 순차 대용량 읽기

랜덤 4KB 읽기 (Cheetah)

• T_seek ≒ 4ms
• T_rotation ≒ 2ms (15K RPM → 4ms/회전 → 평균 2ms)
• T_transfer ≒ 매우 작음 (~0.03ms)
• TI/O ≒ 6ms → 약 0.66 MB/s 수준

순차 100MB 읽기 (Cheetah)

• T_seek + T_rotation : 처음 한 번만 부담
• T_transfer : 100MB / 125MB/s ≒ 0.8초
• RI/O ≒ 125 MB/s (전송률 한계에 근접)

→ 결론

• 같은 디스크에서도 랜덤 vs 순차 성능 차이가 200~300배까지 납니다.
• 디자인 팁: “가능하면 순차 I/O, 안 되면 최소한 큰 덩어리로 I/O 하자.”

---

5. 디스크 스케줄링: SSTF, SCAN, SPTF

5-1. 디스크 스케줄러의 목적

여러 개의 대기 중인 I/O 요청 중, 어떤 것을 먼저 처리해야
총 I/O 시간이 줄어들까?

CPU 스케줄링의 SJF(Shortest Job First)처럼,
디스크는 “완료 시간이 가장 짧을 것 같은 요청”을 먼저 처리하고 싶어합니다.

5-2. SSTF (Shortest Seek Time First)

• 핵심 아이디어 : “가장 가까운 트랙의 요청부터 처리하자.”
• 실제 OS에서는 디스크 내부 지오메트리를 모르므로, “가장 번호가 가까운 블록”으로 근사 (NBF).
• 문제 : starvation(기아)
  • 현재 위치 근처로 계속 새로운 요청이 오면, 멀리 있는 요청은 영원히 못 돌 수도 있음.

5-3. SCAN / C-SCAN – Elevator 알고리즘

• SCAN:
  • 헤드가 한 방향으로만 쭉 움직이며, 그 방향 상의 요청들을 순서대로 처리.
  • 끝까지 갔다가 방향을 바꿔 다시 반대 방향으로 쭉.
• C-SCAN:
  • 한 방향 (예: 바깥 → 안쪽)으로만 처리.
  • 끝까지 갔으면, 반대 방향은 “리셋”처럼 한 번에 돌아와 다시 같은 방향으로만 서비스.
• 효과:
  • 엘리베이터처럼 “현재 방향 기준으로” 요청을 처리 → 기아 방지.
  • 중간 트랙에 편향되는 현상을 줄일 수 있음(C-SCAN).

5-4. SPTF(SATF): Shortest Positioning Time First

SSTF는 seek 거리만 보고 결정합니다. 그런데 실제 I/O 시간은 seek + rotation이므로, 두 개를 합친 “positioning time”을 기준으로 고르는 것이 더 SJF에 가깝습니다.

• SPTF / SATF:
  • “seek + rotation”을 모두 고려해서, 가장 빨리 끝날 요청을 선택.
• 문제:
  • OS는 디스크의 정확한 헤드 위치, 트랙/섹터 배치를 모릅니다.
  • → 이런 정보는 디스크 컨트롤러 내부에서만 정확히 알 수 있음.

5-5. 현대 시스템에서 스케줄링은 어디서 하나?

• 옛날:
  • OS가 스케줄링을 전부 수행 → 한 번에 하나씩 디스크에 요청.
• 요즘:
  • 디스크는 여러 개의 outstanding 요청을 받을 수 있음.
  • OS는 “좋아 보이는 요청들” 몇 개(예: 16개)를 묶어서 디스크에 전달.
  • 실제 순서는 디스크 내부 스케줄러가 SPTF 비슷한 방식으로 최적화.

5-6. I/O merging & anticipatory scheduling

• I/O merging:
  • 예: 33번, 34번 블록을 따로 읽는 요청 → 한 번에 2블록 연속 요청으로 합치기.
  • 리퀘스트 수를 줄이고, 전송을 더 키워서 효율↑
• Anticipatory scheduling:
  • 항상 “온 요청 바로 발사”가 최선은 아니다.
  • 조금 기다리면 더 좋은(인접한) 요청이 올 가능성이 있음.
  • 의도적으로 잠깐 기다리는 non-work-conserving 전략.

---

6. OS / 면접 / 실무용 핵심 정리

6-1. 개념 요약

• 디스크 I/O 시간 = Seek + Rotation + Transfer
• 랜덤 vs 순차 : HDD에서 수백 배 성능 차이까지 난다.
• 트랙 스큐 & 존 : 연속 I/O 유지 & 바깥 트랙에서 더 높은 전송률.
• 디스크 캐시 : 읽기 트랙 버퍼, 쓰기 시 write-back vs write-through.
• 스케줄링:
  • SSTF: 가까운 트랙 우선, 기아 가능.
  • SCAN / C-SCAN: 엘리베이터, 기아 방지.
  • SPTF: seek + rotation 둘 다 고려하는 이상적인 방식 (보통 디스크 내부에서 수행).

6-2. 시험 / 면접용 한 줄 정의

• “디스크는 연속 I/O를 사랑하고, 랜덤 I/O를 미워한다.”
• “HDD 성능은 거의 모두 헤드 이동 + 회전 대기 시간에서 결정된다.”
• “OS는 요청을 잘 정렬하고 합치고, 디스크는 내부에서 SPTF 비슷하게 최적화한다.”

6-3. 실무에서 기억하면 좋은 팁

• 가능하면 순차적인 파일 레이아웃을 유지하도록 설계.
• 로그/저널/배치 작업 등은 큰 덩어리 단위로 쓰기.
• 랜덤 접근이 불가피한 경우:
  • 캐시/버퍼링/배치 I/O를 통해 랜덤을 순차처럼 보이게 만들 수 없는지 고민.