본문으로 건너뛰기

FDP PoC 반복실험 재해석: host write 감소는 FDP 확정 효과 아님

작성일: 2026-06-19 관련 결과 리포트:

한 줄 결론​

72 measurement run 반복실험에서 세 모드(no_fdp / mixed / separated)의 LMCache replay operation 수는 동일했다. 따라서 평균에서 관측된 separated의 host write delta 감소는 FDP placement로 인한 확정적 애플리케이션 write 감소가 아니라, 현재 측정 조건에서 관측된 SMART controller counter 차이로 해석해야 한다. WAF ratio가 세 모드 거의 동일했던 것도 이 해석을 지지한다.

반복실험 관측 (72 measurement run, 3 mode 공통)​

항목no_fdp / mixed / separated 공통
measurement run 수72
finish_write count105,728
reserve_write count105,728
prefetch count6,464
errors0

즉 store/prefetch operation 수가 세 모드 동일 → separated가 store operation을 덜 수행해서 host write가 적어진 것이 아니다.

host write가 적어 보인 이유​

  1. host_write_bytes_delta는 애플리케이션 logical write 합산이 아니라 NVMe SMART Data Units Written 차이다.

    • harness가 쓴 "논리적 KV store bytes"를 직접 더한 값이 아님.
    • measurement_after - measurement_after_warmup 으로 잡은 SSD controller counter.
    • 코드 근거: parse_results.py는 이 값을 harness summary.json에서 그대로 읽고 (summarize_run의 host_write_bytes_delta = summary.get(...)), 두 결과 리포트의 "Counter consistency" 표에서 Internal host delta == Outer SMART delta 가 바이트까지 일치한다 (예: no_fdp 385,622,528,000 동일). 즉 harness 내부값 자체가 nvme smart-log의 data_units_written before/after 차이다.

  2. mode별 실제 write path는 거의 같고, FDP는 placement directive만 다르다.

    • no_fdp / mixed / separated 모두 use_uring_cmd=true.
    • 차이는 use_fdp=false 냐, FDP directive dtype/dspec(RUH 할당)을 넣느냐 정도.
    • 그러니까 host write 감소를 "FDP가 앱 write 자체를 줄였다"로 설명하면 안 된다.

  3. 반복실험에서도 일관된 mode 효과는 아니다.

    • 평균은 separated host write가 가장 낮지만, trial별로 보면 고정된 패턴이 아니다.
    • 예: trial_03 은 no_fdp 464.10GiB, separated 473.62GiB 로 오히려 separated가 더 큼.

  4. R0 precondition / discard / controller 내부 상태 / counter capture timing 영향 가능성.

    • 각 mode 전에 blkdiscard + 32GiB fill + random overwrite(≈64GiB write)를 수행.
    • SMART host counter는 SSD/controller 관점의 data units written이라, 직전 상태·write coalescing·deferred work·namespace/controller counter 특성에 영향을 받을 수 있다.

더 강하게 말할 수 있는 점 (op 동일 ⇒ artifact)​

replay op 수가 세 모드 동일(finish_write 105,728 each)이라면 앱이 장치로 보낸 host write 총량도 모드 간 같아야 한다. 그런데 단일 batch 리포트의 SMART host delta는 no_fdp 475.96 / mixed 466.29 / separated 348.08 GiB 로 ~127GiB 벌어졌다. op가 같은데 이만큼 벌어지는 것은 "FDP가 앱 write를 줄였다"로는 원리적으로 설명되지 않으며, R0 잔여·counter capture window·controller deferred write가 delta에 섞인 측정 artifact라는 뜻이다.

그리고 WAF ratio가 세 모드 모두 ≈ 1.0159 로 동일했던 것이 결정적 근거다 — 실제로 placement 분리가 내부 GC copy를 줄였다면 separated의 WAF가 떨어졌어야 하는데 떨어지지 않았다.

권장 리포트 표현​

반복실험 평균에서 separated의 host/media write delta가 낮게 관측되었지만, replay operation 수는 세 모드가 동일하고 trial별 방향도 완전히 일관되지는 않았다. 따라서 host write 감소는 FDP placement로 인한 확정적 애플리케이션 write 감소라기보다, 현재 측정 조건에서 관측된 controller counter 차이로 해석해야 한다.

지금 확실히 말할 수 있는 것은: store/prefetch operation 수는 세 모드 동일했고, SMART host write delta만 달랐으며, WAF ratio는 거의 같았다는 것뿐이다. host write 감소를 FDP 효과로 단정할 수 없다.

후속​

  • 정식 FDP 효과(WAF/endurance)를 주장하려면, op 수가 동일한 조건에서 host write delta가 아니라 media write / WAF ratio가 mode 간 통계적으로 분리되는지를 봐야 한다. 현재는 분리 안 됨.
  • counter artifact를 줄이려면 R0 span 확대(256/512GiB) 또는 counter capture window를 mode별로 동일 길이·동일 settle로 고정한 재실험이 필요하다 (단일 batch 리포트의 "next step"과 동일 방향).