FDP PoC 단계 4 — 1차 WAF 측정 runbook

목표는 tensormesh 통합 전에 PoC 자체 harness로 FDP 효과 신호를 빠르게 확인하는 것이다.

입력

smrc에서 단계 2/3 이후 아래 env를 맞춘다.

export REPO=/home/ny/work/LMCache-fdp-poc-src
export NVME_IO_DEV=/dev/ng0n1
export NVME_DEV=/dev/nvme0
export NVME_NS=/dev/nvme0n1
export OUT=$HOME/fdp_measure
export FDP_RUH_COUNT=8
export VENDOR_MEDIA_WRITE_COMMAND=""
export TRACE_SCALE=smoke
export DISABLE_MODE_WINDOW_SHIFT=1

VENDOR_MEDIA_WRITE_COMMAND는 단계 2 media_write_counter_probe.txt에서 가용 명령이 확인되면 넣는다. 현재 target에서는 OCP SMART log가 Physical media units written을 제공한다.

export VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json"

없으면 빈 문자열로 두고, 1차 결론은 host_write_bytes_delta와 RUH usage 중심으로 본다.

실행 순서

실제 run은 /dev/ng0n1 raw open 때문에 root 권한이 필요하다. R0는 blkdiscard /dev/nvme0n1를 실행하므로 target namespace가 지워져도 되는지 확인한 뒤 실행한다.

R0는 원문 PoC의 "clean state에서는 WAF가 잘 안 보일 수 있으므로 sustained state preconditioning이 필요하다"는 조건을 반영한다. 현재 스크립트는 whole namespace를 discard한 뒤, harness가 실제로 쓰는 raw-device window span을 sequential fill + random overwrite한다. 기본 precondition span은 harness 기본 base offset인 2199023255552 bytes에서 32 GiB다.

주요 R0 env:

Env	기본값	의미
`R0_CONFIRM`	unset	destructive 실행 확인. 실제 실행에는 `YES` 필요
`PRECONDITION_OFFSET_BYTES`	`2199023255552`	precondition할 측정 window 시작 offset
`PRECONDITION_SIZE_GB`	`32`	sequential fill/random overwrite span
`PRECONDITION_RANDOM_OVERWRITE`	`1`	sequential fill 후 random overwrite 수행
`PRECONDITION_RANDOM_PASSES`	`1`	random overwrite pass 수
`PRECONDITION_RANDOM_RUNTIME_SECONDS`	`0`	0이면 size 기반, 값이 있으면 time-based random overwrite

PRECONDITION_SIZE_GB=auto를 주면 PRECONDITION_OFFSET_BYTES부터 namespace 끝 1GiB 전까지를 자동 계산한다. 원문 PoC에 더 가까운 full-device sustained-state 평가는 PRECONDITION_OFFSET_BYTES=0 PRECONDITION_SIZE_GB=auto로 수행한다. 시간이 오래 걸리므로 1차 smoke에서는 기본 32GiB window-local precondition을 쓸 수 있지만, 최종 WAF 주장은 full-device 또는 충분히 큰 span preconditioning 결과를 우선한다.

cd /path/to/copied/04_measure

# R0: destructive. NVMe namespace 내용을 지운다.
R0_CONFIRM=YES bash run_R0_precondition.sh

# R1/R2/R3: PoC harness 비교. 첫 실행 때 synthetic trace/config를 생성한다.
bash run_poc_harness.sh no_fdp
R0_CONFIRM=YES bash run_R0_precondition.sh
bash run_poc_harness.sh mixed
R0_CONFIRM=YES bash run_R0_precondition.sh
bash run_poc_harness.sh separated

python3 parse_results.py "$OUT" > "$OUT/results_summary.csv"
python3 write_report.py "$OUT" > "$OUT/report.md"
tar czf fdp_measure.tar.gz -C "$HOME" fdp_measure

README 기준 정식 WAF 3모드 batch 예:

cd /home/ny/work/fdp/04_measure

for mode in no_fdp mixed separated; do
  sudo env \
    HOME=/home/ny \
    NVME_DEV=/dev/nvme0 \
    NVME_NS=/dev/nvme0n1 \
    FDP_ENDGRP_ID=1 \
    OUT=/home/ny/fdp_measure_waf_r0 \
    R0_CONFIRM=YES \
    PRECONDITION_OFFSET_BYTES=2199023255552 \
    PRECONDITION_SIZE_GB=32 \
    PRECONDITION_RANDOM_OVERWRITE=1 \
    PRECONDITION_RANDOM_PASSES=1 \
    VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
    bash run_R0_precondition.sh

  sudo env \
    HOME=/home/ny \
    REPO=/home/ny/work/LMCache-fdp-poc-src \
    NVME_DEV=/dev/nvme0 \
    NVME_NS=/dev/nvme0n1 \
    NVME_IO_DEV=/dev/ng0n1 \
    FDP_ENDGRP_ID=1 \
    FDP_RUH_COUNT=8 \
    TRACE_SCALE=stress \
    WARMUP_ITERATIONS=2 \
    MEASUREMENT_ITERATIONS=8 \
    REPLAY_SETTLE_SECONDS=30 \
    POST_MEASURE_SETTLE_SECONDS=360 \
    VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
    DISABLE_MODE_WINDOW_SHIFT=1 \
    WINDOW_START_OFFSET_BYTES=2199023255552 \
    OUT=/home/ny/fdp_measure_waf_r0 \
    bash run_poc_harness.sh "$mode"
done

/usr/bin/python3 parse_results.py /home/ny/fdp_measure_waf_r0 \
  > /home/ny/fdp_measure_waf_r0/results_summary.csv

/usr/bin/python3 write_report.py /home/ny/fdp_measure_waf_r0 \
  > /home/ny/fdp_measure_waf_r0/report.md

빠른 smoke/debug만 필요할 때는 WARMUP_ITERATIONS=0, MEASUREMENT_ITERATIONS=1로 낮춘다. 이 축소 run은 README 기준 정식 결과로 보고하지 않는다.

원문 PoC에 가장 가까운 full-span R0 예:

sudo env \
  HOME=/home/ny \
  NVME_DEV=/dev/nvme0 \
  NVME_NS=/dev/nvme0n1 \
  FDP_ENDGRP_ID=1 \
  OUT=/home/ny/fdp_measure_waf_r0_full \
  R0_CONFIRM=YES \
  PRECONDITION_OFFSET_BYTES=0 \
  PRECONDITION_SIZE_GB=auto \
  PRECONDITION_RANDOM_OVERWRITE=1 \
  PRECONDITION_RANDOM_PASSES=1 \
  VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
  bash run_R0_precondition.sh

sudo 가능한 smrc shell에서 Codex 작업 디렉터리 기준 최소 smoke 실행:

cd /home/ny/work/fdp/04_measure
sudo env \
  HOME=/home/ny \
  REPO=/home/ny/work/LMCache-fdp-poc-src \
  NVME_DEV=/dev/nvme0 \
  NVME_NS=/dev/nvme0n1 \
  NVME_IO_DEV=/dev/ng0n1 \
  FDP_ENDGRP_ID=1 \
  FDP_RUH_COUNT=8 \
  TRACE_SCALE=smoke \
  WARMUP_ITERATIONS=0 \
  MEASUREMENT_ITERATIONS=1 \
  OUT=/home/ny/fdp_measure \
  bash run_poc_harness.sh no_fdp

no_fdp가 통과하면 같은 방식으로 mixed, separated를 실행한다. R0 precondition은 destructive라 별도 확인 후 실행한다.

Codex dry-run 검증:

DRY_RUN=1 TRACE_SCALE=smoke MEASUREMENT_ITERATIONS=1 WARMUP_ITERATIONS=0 \
  OUT=/home/ny/work/fdp_measure_dry bash run_poc_harness.sh no_fdp

위 dry-run은 no_fdp, mixed, separated 모두 통과했다. synthetic trace 생성, 8-RUH config patch, CLI wrapper, replay command construction이 동작한다.

현재 Codex 세션에서 actual run을 직접 실행하려고 하면 sudo password TTY 제한으로 막힌다.

sudo: a terminal is required to read the password
sudo: a password is required

따라서 actual smoke는 sudo 가능한 shell에서 이 runbook의 명령을 실행한 뒤, /home/ny/fdp_measure/results_summary.csv와 run directory를 기준으로 해석한다.

2026-06-12 첫 actual run은 모든 replay worker가 lmcache.native_storage_ops import 실패로 종료되어 무효 처리했다. 이후 native_storage_ops 단독 빌드 산출물을 PoC repo의 lmcache/ package에 배치했고, PoC SMART capture도 nvme smart-log -o json으로 수정했다. 재실행 결과는 실패 run과 섞지 않기 위해 /home/ny/fdp_measure_retry에 받는다.

Run 해석

no_fdp: FDP off baseline
mixed: FDP는 켜되 같은 RUH pool을 공유하는 ablation
separated: worker/storage class별 data RUH와 metadata RUH를 분리

우선 비교:

R1 no_fdp vs R3 separated: 메인 효과
R2 mixed vs R3 separated: 효과 원천이 FDP 자체인지, lifetime/RUH 분리인지 확인

산출물

각 run 디렉터리:

summary.json, summary.md: harness 기본 요약
measurement_*.json: SMART/FDP/vendor counter 스냅샷
worker_logs/*/*/records.jsonl: per-op latency 원본

전체:

results_summary.csv: measurement 구간 기준 run별 WAF/host write/media write/p99/failure count/FDP proxy 요약
report.md: batch-level markdown report. 각 run의 summary.md 링크 포함
generated/: synthetic .lct trace와 config.generated.yaml

현재 target은 nvme fdp configs 기준 RUH 8개다. run_poc_harness.sh는 PoC generator가 요구하는 128-RUH template으로 trace/config를 만든 뒤, 실행 직전에 modes를 8-RUH 장비용으로 다시 쓴다.

DISABLE_MODE_WINDOW_SHIFT=1이 현재 기본값이다. mode별 raw-device window를 +64 GiB, +128 GiB로 이동시키는 실험은 separated host write delta를 0으로 만든 원인으로 확인됐으므로, 비교 run에서는 shift를 끈다. 해당 실험이 필요할 때만 명시적으로 DISABLE_MODE_WINDOW_SHIFT=0을 준다.

반복 실험

1회 결과는 동작 확인에는 충분하지만 재현성 판단에는 부족하다. 반복 실험은 동일 조건을 유지한 채 trial만 늘린다.

cd /home/ny/work/fdp/04_measure

sudo env \
  HOME=/home/ny \
  REPO=/home/ny/work/LMCache-fdp-poc-src \
  NVME_DEV=/dev/nvme0 \
  NVME_NS=/dev/nvme0n1 \
  NVME_IO_DEV=/dev/ng0n1 \
  FDP_ENDGRP_ID=1 \
  FDP_RUH_COUNT=8 \
  TRACE_SCALE=stress \
  WARMUP_ITERATIONS=2 \
  MEASUREMENT_ITERATIONS=8 \
  REPLAY_SETTLE_SECONDS=30 \
  POST_MEASURE_SETTLE_SECONDS=360 \
  RUN_R0_EACH_MODE=1 \
  R0_CONFIRM=YES \
  PRECONDITION_OFFSET_BYTES=2199023255552 \
  PRECONDITION_SIZE_GB=32 \
  PRECONDITION_RANDOM_OVERWRITE=1 \
  PRECONDITION_RANDOM_PASSES=1 \
  VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" \
  REPEATS=3 \
  ORDER_STRATEGY=rotate \
  OUT=/home/ny/fdp_measure_repeats \
  bash run_repeated_trials.sh

기본값:

REPEATS=3
ORDER_STRATEGY=rotate
MODE_SEQUENCE=no_fdp,mixed,separated
RUN_R0_EACH_MODE=1이면 각 mode 실행 직전에 R0 precondition 수행
DISABLE_MODE_WINDOW_SHIFT=1

산출물:

batch_*/trial_*/results_summary.csv: trial별 3모드 요약
batch_*/trial_*/report.md: trial별 report. 각 run의 summary.md 링크 포함
batch_*/trial_plan.csv: trial별 실행 순서
batch_*/repeated_summary.csv: 전체 per-run + mode aggregate 요약

ORDER_STRATEGY=rotate는 순서 bias를 줄이기 위해 trial마다 시작 모드를 바꾼다.

아직 tensormesh 전 단계인 이유

이 harness는 storage-level replay라 TTFT는 측정하지 못한다. no_fdp 대비 separated, 그리고 mixed 대비 separated에서 WAF나 RUH 분포 효과가 확인되면, 그 다음 tensormesh용 R4/R5 스크립트를 별도로 붙이는 순서가 맞다.

입력​

실행 순서​

Run 해석​

산출물​

반복 실험​

아직 tensormesh 전 단계인 이유​

입력

실행 순서

Run 해석

산출물

반복 실험

아직 tensormesh 전 단계인 이유