Storage Systems & Hardware Interfacing

1. Overview

저장 시스템 및 하드웨어 인터페이스(Storage Systems & Hardware Interfacing, SHO)는 추상적인 폴더와 파일이라는 개념이, 실제 하드디스크(HDD)의 빙글빙글 도는 자성 플래터나 솔리드 스테이트 드라이브(SSD)의 미세한 반도체 트랜지스터(NAND Cell)에 어떻게 물리적으로 구워지는지를 해부하는 최저수준(Low-level) 시스템 역학을 다룹니다.

데이터베이스 엔지니어나 백엔드 개발자가 작성한 쿼리가 최상의 성능을 내려면 디스크 하부의 물리적 한계를 알아야 합니다. 학습자는 파일의 메타데이터를 담고 있는 아이노드(Inode) 구조, 덮어쓰기(Overwrite)가 불가능한 플래시 메모리의 치명적 단점을 가려주는 FTL(Flash Translation Layer)의 마법, 그리고 초당 수백만 번의 I/O를 꽂아 넣기 위해 커널(Kernel)을 통째로 우회하는 NVMe와 SPDK 기반의 제로 카피(Zero-copy) 기술을 학습하여 시스템 병목을 하드웨어 바닥에서부터 타파합니다.

2. Scope & Boundaries

In-Scope

• 파일 시스템 물리 (File System Internals): 아이노드(Inode), 디렉토리 구조(Dentry), 하드 링크 vs 심볼릭 링크, VFS(Virtual File System) 추상화.
• 플래시 메모리와 FTL (SSD Physics): NAND 셀 구조(SLC/MLC/TLC), 덮어쓰기 불가(Erase-before-write) 한계, 웨어 레벨링(Wear Leveling), 쓰기 증폭(Write Amplification).
• I/O 스택과 캐싱 (I/O Stack): 페이지 캐시(Page Cache), 더티 페이지(Dirty Page) 플러시, 다이렉트 I/O(Direct I/O)를 통한 커널 우회 물리.
• 차세대 초고속 인터페이스 (Extreme I/O): SAS/SATA 한계, NVMe 다중 큐잉(Command Queues) 아키텍처, 커널 인터럽트 vs 폴링(Polling) 모드 I/O.

Out-of-Scope

• 운영체제의 일반적인 메모리(RAM) 스와핑(Swapping): 휘발성 메모리를 관리하는 OS의 페이징 기법 → 03-03. Memory Management 영역으로 위임.
• 네트워크 스토리지 클러스터 (Ceph, S3): 여러 대의 컴퓨터를 묶어 만드는 객체 스토리지나 분산 파일 시스템의 분산 합의 구조 → 06-03. Distributed Logic 영역으로 위임.

Boundaries

• SHO vs. Database Tuning (06-01): 06-01(RS)의 튜닝이 '인덱스를 잘 타도록 SQL 쿼리 문법을 바꾸는 논리적 행위'라면, SHO는 **'그 인덱스 트리가 결국 SSD의 4KB 블록에 쓰일 때 발생하는 물리적 쓰기 증폭을 어떻게 통제할 것인가'**라는 하드웨어 매핑 장막 아래를 파고듭니다.

3. Counterexample

• SSD 덮어쓰기 오해와 트림(TRIM) 방치 (Hardware Fallacy): 애플리케이션에서 동일한 파일에 데이터를 100번 덮어쓸 때, "HDD처럼 같은 디스크 위치(Sector)의 자성을 100번 바꿀 것"이라고 착각하는 행위. SSD의 NAND 셀은 물리적으로 덮어쓰기가 불가능하여 매번 새로운 빈 블록을 찾아 데이터를 기록하고 이전 블록은 '쓰레기(Invalid)'로 마킹하는 파편화 지옥에 빠집니다. OS에서 백그라운드로 이 쓰레기를 치우는 TRIM 명령어와 내부 가비지 컬렉션(GC) 동작을 고려하지 않고 미친 듯이 랜덤 쓰기를 날리면 SSD 수명(P/E Cycle)이 몇 달 만에 증발하는 안티패턴입니다.
• 페이지 캐시 오해 (I/O Fallacy): write() 시스템 콜이 리턴되자마자 전원 코드를 뽑았는데 데이터가 날아간 것을 보고 DB 버그라고 분노하는 현상. write()는 디스크에 도달한 것이 아니라 운영체제 메모리상의 **페이지 캐시(Page Cache)**에 더티(Dirty) 상태로 머물러 있을 뿐입니다. 물리적 디스크 플러시(fsync)가 호출되지 않으면 정전 시 데이터가 100% 날아간다는 OS I/O 스택의 지연 기록(Write-back) 물리를 이해하지 못한 것입니다.

4. Prerequisites

• 디지털 논리 및 프로세서 (Basic): NAND 트랜지스터에 전자가 갇혀 0과 1을 기억하는 최소한의 전기적 매커니즘 이해가 SSD 학습의 밑바탕이 됩니다. (02-01. Digital Logic)
• 운영체제 시스템 콜 (Recommended): 파일 I/O를 요청할 때 커널 모드로 진입하여 컨텍스트 스위칭이 일어나는 물리적 오버헤드를 체감해야 합니다. (03-02. PCM)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 파일 시스템 구조와 아이노드 역학 (File Systems & Inodes)

• Why to Learn: 리눅스에서 "용량이 남았는데 파일이 더 이상 안 만들어져요!"라는 황당한 장애(No space left on device)가 아이노드 고갈 때문임을 즉각 간파하기 위함입니다.
• What to Learn:
  • Concepts: 아이노드(Inode), 메타데이터(퍼미션, 타임스탬프, 크기), 데이터 블록 포인터(Direct/Indirect Block).
  • Skills: 디렉토리를 단순한 '파일 이름 → Inode 번호 맵핑 테이블'로 이해하기, 하드 링크(Hard Link)의 참조 카운팅 물리, 심볼릭 링크(Soft Link)와의 파괴적 횡단 차이.
  • Tools: 리눅스 stat, ls -i, df -i.
  • Trade-offs: 파일 접근 속도를 극대화하기 위해 아이노드를 디스크 앞단에 몰아넣는 구조 vs 디스크 크기가 테라바이트를 넘어가면 아이노드 탐색 후 실제 데이터 블록으로 갈 때 디스크 헤드가 대륙을 횡단해야 하는 탐색 지연(Seek Time) 오버헤드.
• How to Learn:
  • 1단계: 빈 파일을 만들고 stat 명령어로 부여된 Inode 번호를 확인한 뒤, 이 파일에 하드 링크를 걸면 전혀 다른 이름임에도 똑같은 Inode 번호를 공유하며 디스크 용량을 1바이트도 더 쓰지 않는 물리를 증명합니다.
  • 2단계: /var/log/my.log 파일을 텍스트 에디터로 열기 위해, 루트(/) 디렉토리 아이노드부터 시작해 var의 데이터 블록을 뒤지고, 다시 log의 아이노드를 찾는 **경로 탐색(Path Resolution)**의 연산 스텝을 다이어그램으로 전개합니다.
• Implement: 특정 문자열(파일 이름)을 입력하면 1부터 100까지의 고정된 가상 Inode 배열을 검색해, 연결된 메모리 블록(데이터) 주소를 반환하는 최소 단위의 VFS(Virtual File System) 트리거 코드.

Recommended

Core Topic 02: 플래시 메모리 물리와 FTL 펌웨어 (SSD Physics & FTL)

• Why to Learn: 초고속 SSD가 쓰면 쓸수록 느려지는 근본적 이유를 깨닫고, 웨어 레벨링과 트림(TRIM) 제어를 통해 데이터베이스 서버의 수명을 연장하기 위해서입니다.
• What to Learn:
  • Concepts: NAND Flash(비휘발성 셀), 페이지(Page, 읽기/쓰기 단위), 블록(Block, 지우기 단위).
  • Skills: Erase-before-write(덮어쓰기 불가), FTL(Flash Translation Layer)의 논리-물리 주소 매핑, 가비지 컬렉션(Garbage Collection), 쓰기 증폭(Write Amplification).
  • Tools: fstrim, SSD 벤더 S.M.A.R.T 도구(셀 마모도 측정).
  • Trade-offs: SLC(1셀 1비트)의 영구에 가까운 10만 번의 쓰기 수명과 압도적 속도 vs 전압 레벨을 8개로 쪼개어 용량을 3배 늘렸지만 수명이 3천 번으로 박살 난 TLC(1셀 3비트)의 가혹한 신뢰성-용량 교환.
• How to Learn:
  • 1단계: 4KB의 데이터 1글자만 수정하려 해도, 덮어쓰기가 안 되어 빈 4KB를 찾아 새 데이터를 쓰고 기존 4KB를 쓰레기(Invalid)로 마킹하는 FTL의 눈물겨운 이면 작업을 도식화합니다.
  • 2단계: SSD에 쓰레기가 꽉 차면 어쩔 수 없이 멀쩡한 데이터까지 통째로 임시 메모리에 옮겼다가 블록 전체를 폭파(Erase)하고 다시 써넣는 과정에서 쓰기 증폭 계수(WAF)가 5~10배로 치솟아 성능이 급락하는 시나리오를 계산합니다.
• Implement: 배열 10개를 물리적 블록으로 두고, '수정' 명령이 들어오면 기존 인덱스를 invalid 처리하고 새 빈 공간에 데이터를 쓴 뒤 논리적 매핑 딕셔너리만 교체하는(LBA → PBA) 미니 FTL 펌웨어 시뮬레이터.

Practical

Core Topic 03: 운영체제 I/O 스택과 버퍼/캐시 물리 (I/O Stack & Direct I/O)

• Why to Learn: 메모리가 64GB나 남았는데 디스크가 100% 혹사당하는 병목을 뚫기 위해, 커널이 데이터를 품었다가 내뿜는 타이밍을 개발자가 직접 쥐고 흔들기 위함입니다.
• What to Learn:
  • Concepts: 페이지 캐시(Page Cache), 버퍼 캐시(Buffer Cache), 더티 페이지(Dirty Page), 동기 I/O vs 비동기 I/O (AIO).
  • Skills: fsync()와 fdatasync()의 디스크 강제 플러시 차이, 커널 메모리 복사를 아예 건너뛰고 유저 공간에서 디스크 컨트롤러로 다이렉트 꽂아버리는 O_DIRECT 플래그 사용.
  • Tools: 리눅스 fio 벤치마크, strace (시스템 콜 트레이싱).
  • Trade-offs: OS의 페이지 캐시가 제공하는 경이로운 읽기 적중률과 쓰기 지연(Write-back) 병합 효율 vs DB 엔진이 자체적으로 캐시를 관리하고 싶은데 OS가 또 캐시를 해버려 램 용량을 두 배로 까먹는 이중 캐싱(Double Caching)의 참사.
• How to Learn:
  • 1단계: 1GB짜리 파일을 C언어로 읽어 들이는 코드를 짤 때, 처음엔 1초가 걸렸지만 두 번째 실행 시 0.05초 만에 끝나는 마법이 디스크가 빨라진 게 아니라 OS 페이지 캐시가 RAM에서 바로 데이터를 뱉어낸 결과임을 free -m 명령어로 증명합니다.
  • 2단계: 데이터베이스 엔진(예: Oracle, MySQL)처럼 자기가 직접 메모리를 통제하려는 소프트웨어는 파일을 열 때 O_DIRECT 플래그를 주어, 무거운 커널을 거치지 않고 유저 스페이스에서 곧장 하드웨어 드라이버로 내려가는 DMA(Direct Memory Access) 경로를 설계합니다.
• Implement: 동일한 100MB 텍스트 파일에 대해, 일반 write()로 캐시를 타게 하는 모드와 O_DIRECT 플래그를 달아 매번 디스크 암을 강제로 긁게 하는 모드의 실제 실행 속도를 밀리초 단위로 비교 출력하는 로우 레벨 벤치마커.

Advanced

Core Topic 04: 극한의 하드웨어 인터페이스와 NVMe 폴링 (NVMe & SPDK)

• Why to Learn: CPU 코어는 64개인데 디스크 컨트롤러에 줄을 서는 큐(Queue)가 1개뿐이라 병목이 걸리던 구시대 아키텍처를 파괴하고, 초당 백만 번의 초고속 I/O를 달성하기 위해서입니다.
• What to Learn:
  • Concepts: PCIe 인터페이스, NVMe(Non-Volatile Memory Express) 다중 큐, 인터럽트(Interrupt) 처리 지연, 폴링(Polling) I/O.
  • Skills: SATA(큐 1개, 깊이 32)와 NVMe(큐 64,000개, 깊이 64,000)의 물리적 파이프라인 차이 분석, SPDK(Storage Performance Development Kit)를 이용한 유저 스페이스 스토리지 드라이버 장악.
  • Tools: nvme-cli, SPDK 프레임워크.
  • Trade-offs: 디스크가 데이터를 다 쓸 때까지 CPU가 다른 일을 하다가 인터럽트 신호를 받고 돌아오는(Interrupt) 효율성 vs "다 썼어? 다 썼어?"를 미친 듯이 무한 루프로 물어보며 CPU 코어 하나를 100% 태우지만, 인터럽트 컨텍스트 스위칭 지연(마이크로초 단위)마저 0으로 지워버리는 폴링(Polling) 기반 극한 스피드의 광기.
• How to Learn:
  • 1단계: SATA 케이블이 꽂히던 HBA 컨트롤러를 거치지 않고, CPU의 PCIe 레인에 곧바로 꽂혀버리는 NVMe SSD의 물리적 회로 단축이 응답 시간(Latency)을 절반 이하로 찢어버리는 통로 다이어그램을 분석합니다.
  • 2단계: 초고성능 스토리지 서버에서 리눅스 커널의 블록 I/O 계층을 완전히 무시해 버리고, 사용자 애플리케이션 코드가 직접 디스크 하드웨어 레지스터에 접근(SPDK)하여 병목 없는 트래픽을 뽑아내는 아키텍처를 스케치합니다.
• Implement: 디스크 작업 완료를 커널 인터럽트로 깨워줄 때까지 스레드를 sleep 상태로 두는 고전적 방식과, while(!done) 무한 루프로 CPU 점유율을 100% 치솟게 하면서 작업 완료 플래그를 폴링(Polling)하는 방식을 비교하여, 후자의 레이턴시 감소 효과를 정량화하는 개념 증명 스크립트.

7. Terminology

8. References

Primary References

• [P1] CS2023 - OS/Storage & File Systems — Storage theory.
• [P5] SFIA - Systems Development — Hardware-software integration skills.

Secondary References

• [Operating Systems: Three Easy Pieces (OSTEP)] Arpaci-Dusseau — Excellent storage chapters.
• [Modern Operating Systems] Andrew S. Tanenbaum — Deep file system analysis.

Industry References

• [Intel/Samsung NVMe Whitepapers] — Hardware interface standards.
• [Linux Kernel Documentation - The Block Layer] — Practical storage stack internals.

9. Final Checklist

Primary Checklist

• 특정 파일 시스템에서 수천 개의 작은 파일을 가진 디렉토리를 탐색할 때 병목이 발생하는 아이노드 레벨의 이유를 설명 가능한가? (P1)
• SSD에서 TRIM 명령어가 실행되지 않았을 때, 장기적인 쓰기 성능이 저하되는 물리적 메커니즘을 기술할 수 있는가? (P1)

Secondary Checklist

• RAID 0, 1, 5, 10의 물리적 배치 차이를 알고 데이터 손실 리스크와 읽기/쓰기 성능 간의 트레이드오프를 평가할 수 있는가?
• 파일 시스템 저널링(Journaling)이 갑작스러운 전원 차단 시 파일 무결성을 어떻게 물리적으로 보호하는지 인지하는가?

Industry Checklist

• 실무 서비스에서 디스크 I/O 대기시간(iowait)이 급증할 때, 이를 iostat 데이터로 분석하여 랜덤 I/O 병목인지 대역폭 포화인지 식별 가능한가? (SFIA)
• 고성능 데이터베이스 서버 구축 시 NVMe 큐 깊이(Queue Depth) 설정이 애플리케이션의 결과 응답 지연에 미치는 영향을 제안할 수 있는가?