Garbage Collection (GC) — SSD 내부

[!tldr] 업무 관점 takeaway SSD의 GC는 [[NAND-Flash-기초|NAND의 erase 단위 > write 단위]] 특성 때문에 반드시 발생한다. 문제는 얼마나 자주, 얼마나 비싸게 발생하느냐. [[KV-Cache]] 워크로드는 lifetime 불균일 + 높은 utilization으로 GC를 폭주시킨다 → [[WAF]] 증가 → write tail latency spike → LMCache warm [[TTFT-ITL|TTFT]] 흔들림. FDP는 정확히 이 GC 비용을 낮추는 메커니즘.

왜 GC가 필요한가

[[NAND-Flash-기초|NAND]]는:

Page 단위로 쓰기/읽기
Block 단위로만 erase
덮어쓰기 불가

즉 "이 페이지를 업데이트" = "다른 페이지에 새로 쓰고 기존 페이지를 invalid 처리". 시간이 흐르면 블록 안에 invalid 페이지가 늘어나지만 erase는 block 단위라 못 지움 → 그 블록을 재활용하려면 GC.

GC 절차

Victim Block 선정 (invalid 페이지 비율 높은 블록)
Valid 페이지들을 다른 블록으로 복사
Victim Block을 erase
이제 그 블록을 새 쓰기에 사용 가능

2번 복사가 [[WAF|Write Amplification]]의 직접 원인.

비용을 결정하는 변수

변수	GC 비용에 미치는 영향
블록 안 valid 페이지 비율	높을수록 복사량 ↑ → 비용 ↑
SSD utilization	높을수록 victim 선택지 ↓ → 빈도 ↑
Lifetime 불균일	짧은 게 지워질 때 긴 게 복사됨
Random write 빈도	superblock에 구멍이 뚫림

GC와 사용자 응답속도 인과 사슬

GC 시점에 들어온 host write
   │
   ▼
GC 작업이 끝날 때까지 대기 (또는 background와 경합)
   │
   ▼
Write latency spike (p99)
   │
   ▼
[[LMCache-Local-Disk-Backend|LMCache async write]] 대기열 적체
   │
   ▼
CPU DRAM에서 evict 못 함 → 메모리 압박 → 결국 throughput ↓

→ GC 폭주는 단순히 SSD가 느려지는 게 아니라 LMCache 전체 파이프라인 backpressure로 전파.

FDP가 GC를 어떻게 줄이나

기존 SSD: append point 1개 → 모든 데이터 섞임 → 블록마다 lifetime 다양 → valid copy 많음 → GC 비쌈.

[[NVMe-FDP|FDP]] SSD: RUH별 append point → 같은 수명 데이터끼리 같은 RU → RU 단위로 동시에 invalid → 복사할 게 없는 erase.

이상적 FDP 시나리오:
RU #0 (single-query KV)
  → 모두 동시에 invalid 됨 (쿼리 끝나면)
  → erase 시 valid copy = 0
  → WAF = 1

측정 시 주의사항

SSD utilization이 낮으면 GC가 거의 안 일어남 → FDP 효과 안 보임. 실험은 utilization 90%+ 에서.
측정 도중 SSD 내부 GC 타이밍에 따라 결과 노이즈. warm-up 후 정상 상태에서 측정.

의외의 연결

[!note] LMCache LRU evict ↔ FDP RU invalidation [[LMCache-Local-Disk-Backend|LMCache의 LRU eviction]]은 .pt 파일 삭제 = TRIM/DEALLOC. 같은 RUH로 그룹화된 파일들이 비슷한 시점에 모두 invalid 되면 → RU 전체가 비어 GC 없이 erase 가능. LRU bucket 자체가 RUH 매핑의 자연스러운 단위.

왜 GC가 필요한가​

GC 절차​

비용을 결정하는 변수​

GC와 사용자 응답속도 인과 사슬​

FDP가 GC를 어떻게 줄이나​

측정 시 주의사항​

의외의 연결​

관련 페이지​