본문으로 건너뛰기

기여 포인트 맵 — Storage Stack 전체 관점

[!tldr] 업무 관점 takeaway "FDP만 보는 게 아니라 LMCache → FS → Block → NVMe Driver → SSD 전체 스택의 어느 레이어든 손댈 수 있다." 이 페이지는 우리 SW팀이 기여 가능한 지점 12개를 스택 다이어그램에 매핑한 마스터 인덱스다. [0] raw block backend 개선이 현재 가장 활발한 영역 (H1/H2/S2/M1/M2 진행 중). SSD 타겟은 Std SSD(1.927.68TB)가 1차, HC SSD(1530TB)가 확장 타겟이다.

Storage Stack과 기여 포인트 매핑​

┌─────────────────────────────────────────────────┐
│                  LMCache Layer                  │
│  [0] raw block backend 개선 ★ 현재 진행 중      │
│      (안정성·성능·운영성 — H1/H2/S2/M1/M2)      │
│  [1] FDP-aware Backend 구현 (Std·HC SSD 공통)   │
│  [2] io_uring 기반 async I/O 지원               │
│  [3] Chunk size / 정렬 최적화                   │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│               File System Layer                 │
│  [4] FS 선택 최적화 (xfs vs ext4 vs f2fs)       │
│  [5] Direct I/O block alignment                 │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│               Block / IO Layer                  │
│  [6] IO Scheduler 튜닝 (mq-deadline vs none)    │
│  [7] Queue Depth 최적화                         │
│  [8] io_uring 직접 연결                         │
└────────────────────┬────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────┐
│         NVMe SSD Layer (Std / HC)               │
│  [9]  FDP 스트림 분리 — Std·HC SSD 공통 적용    │
│  [10] SSD 타입별 Host Control (HC 핵심, Std 포함) │
│  [11] WAF 측정 및 개선                          │
└─────────────────────────────────────────────────┘

포인트별 구체화​

[0] raw block backend 개선 (LMCache layer) ★ 현재 진행 중​

raw block은 LMCache에서 NVMe를 직접 다루는 핵심 백엔드. FDP/io_uring 기능 추가 전에 기반을 다지는 작업.

항목내용상태
H1_free_slots O(n) → O(1) (set 병렬 유지)착수 가능
H2LIFO → FIFO 슬롯 재사용 (wear leveling)착수 가능
M1non-MP 경로 io_uring 실질 연결#3274 머지 후
M2io_uring setup flag 튜닝#3274/#3271 머지 후
S2checkpoint payload overflow fix (Std SSD 3.84TB+ 영향)Daejun 협의 대기
S1non-MP evictiondaegyu94 #3394 진행 중 — 착수 금지
  • 관련: [[raw_block-개선-Task]], [[raw_block-내부구조]], [[S2-checkpoint-overflow]]

[1] FDP-aware Backend (LMCache layer)​

  • LMCache의 플러그인 구조를 활용해 FDP를 인식하는 새 Backend 구현
  • 청크 write 시 [[NVMe-FDP|FDP placement identifier]] (RUH) 할당 → hot/cold 분리
  • FDP는 NVMe 스펙 — HC SSD(QLC, 핵심 타겟)와 Std SSD 양쪽에 적용. HC SSD에서 FDP 효과가 더 두드러지는 이유는 QLC 특성(WAF 민감도 ↑) 때문이지, FDP가 HC 전용이어서가 아님.
  • upstream PR이 이상적 목표 — "LMCache 공식 문서에 우리 SSD 레퍼런스 등재"
  • 관련: [[LMCache-Local-Disk-Backend]], [[NVMe-FDP]]

[2] io_uring 기반 async I/O (LMCache layer)​

  • 현재 [[LMCache-Local-Disk-Backend]]는 스레드 풀(4 worker)로 sync I/O를 비동기처럼 흉내
  • 진짜 async I/O인 [[io_uring]]으로 교체 시
    • syscall 오버헤드 ↓
    • 스레드 컨텍스트 스위치 ↓
    • FDP placement hint도 같은 경로로 전달 가능
  • 의외의 시너지: [1]과 [2]를 함께 구현하면 자연스럽게 결합

[3] Chunk size / 정렬 (LMCache layer)​

  • 기본 LMCACHE_CHUNK_SIZE=256 토큰 → 실제 byte 크기는 모델/설정마다 다름
  • Llama-3.1-8B 기준 256토큰 ≈ 134MB (계산: 2×32×32×128×2bytes×256)
  • NVMe optimal transfer size, FDP RU size와 정렬되는지 측정·문서화 필요
  • 자동 정렬 로직 추가 가능

[4] FS 선택 (FS layer)​

  • LMCache는 "청크 하나 = 파일 하나" → small/medium file이 폭주
  • ext4 vs xfs vs f2fs 중 어떤 게 이 패턴에 유리한지 측정
  • f2fs는 NAND-aware FS → 자체 hot/cold 분리 기능 있음 (FDP와 중첩 가능성 검토)

[5] Direct I/O alignment (FS layer)​

  • LMCache에 use_odirect=True 옵션 존재 → [[O_DIRECT]] 사용 가능
  • 단, alignment 조건 (버퍼/크기/offset 모두 512B 또는 4KB 정렬) 미준수 시 silently fallback
  • 현재 코드가 alignment를 보장하는지 검증, 깨지면 fix 기여

[6] IO Scheduler 튜닝 (Block layer)​

  • NVMe에서는 보통 none 추천이지만, 동시 read/write 워크로드에선 mq-deadline이 tail latency 안정화에 도움
  • LMCache 워크로드 (prefetch read + async write 동시) 특성 측정 후 권고안 도출

[7] Queue Depth (Block layer)​

  • LMCache는 batched_async_contains로 멀티 파일 동시 read → NVMe QD 급상승
  • 최적 QD 측정, 너무 깊으면 tail latency 악화

[8] io_uring 직접 연결 (Block layer)​

  • [2]와 동일선상. LMCache가 직접 io_uring을 쓰면 Block layer를 거치지 않고 NVMe에 명령 전달 가능 (io_uring_cmd / passthru)
  • [[NVMe-FDP]] placement hint 전달의 정석 경로

[9] FDP 스트림 분리 — hot/cold KV (SSD layer)​

  • LMCache의 LRU/LFU 정책 결정을 그대로 RUH 매핑에 사용
  • prefix cache (long-lived) ↔ single-query cache (short-lived) 분리
  • 의외의 연결: [[LMCache-Local-Disk-Backend]]의 priority queue (PREFETCH > DELETE > PUT) 우선순위가 그대로 RUH 그룹화 힌트로 쓸 수 있음

[10] SSD 타입별 Host Control 최적화 (SSD layer)​

  • HC SSD (15~30TB, QLC): 핵심 타겟. write latency / WAF 민감도 ↑ → FDP로 WAF를 ~1.0으로 낮추지 않으면 QLC 가성비 의미 없음. FDP 효과가 가장 두드러지는 미디어.
  • Std SSD (1.92~7.68TB, TLC): 함께 포함되는 타겟. FDP 적용 가능하며, HC SSD 대비 WAF 민감도가 낮아 효과는 상대적으로 작음. S2(checkpoint overflow) 같은 버그는 Std SSD 3.84TB+에도 해당.

[11] WAF 측정 및 개선 (SSD layer)​

  • nvme fdp stats /dev/nvmeX 명령으로 WAF 측정
  • baseline (FDP off) vs FDP on 비교 → Meta CacheLib 사례(3.5→1) 재현 여부 검증
  • 관련: [[CacheLib-FDP-사례]]

우선순위 (현재 단계 기준)​

★ 진행 중 — [0]           raw block 개선 (H1/H2/S2/M1/M2 — 지금 손대고 있음)
1순위    — [3], [5], [11] (단기 검증 가능, baseline 측정)
2순위    — [1], [9]       (FDP Backend 자체)
3순위    — [2], [8]       (io_uring — 큰 변경, 큰 효과)
보조     — [4], [6], [7], [10] (튜닝 가이드 문서화)

의외의 연결​

[!note] [1]+[2]는 한 묶음 FDP Backend 만들 때 어차피 [[io_uring|io_uring_cmd]]로 NVMe passthru 경로를 타게 된다 ([[NVMe-FDP]]에서 다룸). 즉 [1] 구현이 사실상 [2]를 강제한다.

[!note] [3] chunk size는 SSD가 아니라 모델이 정한다 chunk size byte 크기는 사용하는 LLM의 hidden dim에 종속. 즉 "Storage 최적값"과 "AI 모델 친화값"이 따로 결정되고, 우리는 둘이 정렬되는 sweet spot을 찾아야 한다.

관련 페이지​

  • [[Mission]] — 이 맵의 상위 목표
  • [[단기-Task-목록]] — 실제로 진행 중인 5개 Task
  • [[Storage-Stack]] — 각 레이어의 기본 개념
  • [[LMCache-Local-Disk-Backend]] — [1][2][3]의 대상 코드
  • [[NVMe-FDP]] — [9][11]의 기반 기술
  • [[raw_block-개선-Task]] — [0] 현재 진행 중 Task (H1/H2/M1/M2/S2)