본문으로 건너뛰기

Storage Stack — FS → Block → NVMe → SSD

[!tldr] 업무 관점 takeaway 우리 작업 공간의 좌표계. LMCache가 .pt 파일을 쓰는 순간부터 NAND에 비트가 굳을 때까지 4개 레이어를 거친다. 각 레이어가 자체적인 캐싱·정렬·스케줄링·재배치를 하는데, 한 레이어의 결정이 다른 레이어 효과를 가린다. 그래서 [[O_DIRECT]]·[[io_uring]]·[[NVMe-FDP|FDP passthru]]처럼 레이어를 건너뛰거나 직결하는 옵션이 측정·튜닝의 핵심.

전체 그림​

┌────────────────────────────────────┐
│ Application (LMCache)              │
│   .pt 파일 write/read              │
│   - torch.save/load                │
│   - 어떤 syscall로? (확인 필요)    │
└──────────────┬─────────────────────┘
               ▼
┌────────────────────────────────────┐
│ File System (ext4 / xfs / f2fs)    │
│   - VFS layer                      │
│   - inode, directory, journal      │
│   - page cache 또는 O_DIRECT       │
└──────────────┬─────────────────────┘
               ▼
┌────────────────────────────────────┐
│ Block Layer                        │
│   - bio 구조 / merge / split       │
│   - I/O scheduler (none, mq-d/l)   │
│   - multi-queue, queue depth       │
└──────────────┬─────────────────────┘
               ▼
┌────────────────────────────────────┐
│ NVMe Driver                        │
│   - submission queue / completion  │
│   - namespace                      │
│   - FDP placement handle 전달      │
└──────────────┬─────────────────────┘
               ▼
┌────────────────────────────────────┐
│ NVMe SSD (FDP / HC-SSD)            │
│   - FTL (LBA → physical)           │
│   - Append point(s), GC, wear lev. │
│   - NAND read/program/erase        │
└────────────────────────────────────┘

각 레이어가 우리에게 미치는 영향​

1. Application (LMCache)​

  • I/O 단위 결정: [[LMCache-Local-Disk-Backend|256 토큰 chunk → 100MB 단위]]
  • I/O 빈도 결정: LRU evict 정책
  • 어떤 syscall을 쓰는지가 결정적 — read/write vs pread/pwrite vs io_uring vs io_uring_cmd

2. File System​

FSLMCache 패턴 적합도
ext4기본값. journaling 오버헤드
xfsmedium/large file에 강함 — LMCache 청크에 유리할 가능성
f2fsNAND-aware. 자체 hot/cold 분리 → FDP와 중첩 가능성 검토
  • [[O_DIRECT]] 옵션이 page cache 우회 → 측정 명료성 ↑
  • O_DIRECT alignment 조건 위반 시 silently fallback ⚠️

3. Block Layer​

  • I/O Scheduler:
    • none — NVMe 기본. 오버헤드 최소.
    • mq-deadline — read/write 동시 워크로드의 tail latency 안정화에 도움 가능.
  • Queue Depth:
    • 너무 얕으면 throughput ↓
    • 너무 깊으면 p99 latency ↑
    • LMCache의 batched_async_contains (→ [[LMCache-Async-Loading]])가 QD를 급격히 올린다.

4. NVMe Driver​

  • Multi-queue 활용 — GPU별 / NUMA별 큐 분리 가능
  • FDP placement handle 전달 경로 — io_uring_cmd로 passthru하면 fs/block layer 우회

5. NVMe SSD (FDP/HC-SSD)​

  • FTL이 LBA → physical 매핑 결정
  • FDP가 켜져 있으면 append point가 RUH 수만큼으로 늘어남
  • GC, wear leveling은 여기서 발생 ([[Garbage-Collection]])

두 가지 경로 — Pass-through vs Through-stack​

[A] FS 경로 (일반)
  App → FS → Block Layer → NVMe Driver → SSD
  ─ 장점: 기존 인프라 그대로
  ─ 단점: 여러 레이어가 결정에 개입 → 측정 노이즈

[B] I/O Passthru 경로 (저지연)
  App → io_uring_cmd → NVMe Driver → SSD
  ─ 장점: FS/Block 우회, FDP 힌트 직접 전달
  ─ 단점: 파일 추상화 없음, raw block에 직접 쓰기

[[NVMe-FDP|FDP]] hint를 가장 안정적으로 전달하려면 경로 [B]. [[LMCache-Local-Disk-Backend|LMCache LocalDiskBackend]]는 현재 [A]를 사용한다고 추정되며, 코드 레벨 검증이 필요.

우리가 손댈 수 있는 레이어별 옵션 (요약)​

레이어옵션관련 페이지
AppI/O 단위, syscall 종류[[LMCache-Local-Disk-Backend]], [[io_uring]]
FSext4/xfs/f2fs, O_DIRECT[[O_DIRECT]]
Blockscheduler, QD[[기여-포인트-맵]] [6][7]
NVMepassthru, namespace[[NVMe-FDP]]
SSDRUH, wear leveling[[NVMe-FDP]], [[HC-SSD]]

전체 우리 손길 매핑: [[기여-포인트-맵]].

측정 도구 (레이어별)​

레이어도구
AppLMCache observability, py-spy, strace
FS / Blockiostat, blktrace, fio, bpftrace
NVMenvme-cli, nvme fdp stats
SSD 내부(벤더 도구 / SMART)

의외의 연결​

[!note] 레이어를 건너뛸수록 측정이 명료해진다 O_DIRECT → page cache 건너뜀. io_uring_cmd → FS+Block 건너뜀. 우리 실험은 점진적으로 레이어를 우회하며 어디서 latency가 사라지고 어디서 안 사라지는지 보는 게 정석.

관련 페이지​

  • [[기여-포인트-맵]] — 각 레이어 작업 포인트 매핑
  • [[LMCache-Local-Disk-Backend]] — App 레이어의 현재 모습
  • [[O_DIRECT]] — FS layer 옵션
  • [[io_uring]] — App ↔ NVMe 직결 옵션
  • [[NVMe-FDP]] — SSD layer 핵심 기능