PoC harness 측정 지표 카탈로그

대상: benchmarks/fdp_waf_stress/run_fdp_waf_stress.py (1456줄) 용도: 단계 4 1차 측정에서 PoC harness가 직접 주는 지표 / 추출 필요한 지표 / 본질적으로 못 주는 지표를 분리. 단계 2 audit·단계 4 runbook 작성 입력. 관련: 03_fdp_implementation_audit.md §1(f), PLAN.md 단계 4 측정 지표

1. 산출 파일 목록

PoC harness 1회 실행(--mode <m> --output-dir <D>)당 <D>/에 떨어지는 파일:

파일	내용	출처
`run_config.resolved.yaml`	입력 config + CLI 인자를 합친 최종 형태	`write_yaml(... resolved)`
`commands.txt`	각 worker에 실제 실행된 `lmcache trace replay` 명령	`build_replay_command()`
`workers.json`	per-worker 메타 (window 할당, RUH 매핑)	`WorkerSpec.to_dict()`
`measurement_before.json`	warmup 시작 직전 SMART/FDP/vendor counter 스냅샷	run_fdp_waf_stress.py:820-879 `capture_measurement("before_warmup")`
`measurement_after_warmup.json`	warmup 끝 시점 (= 측정 시작 기준점)	동일
`measurement_after.json`	측정 끝 시점	동일
`summary.json`	warmup→측정 구간 delta 기반 결과 표	run_fdp_waf_stress.py:1131-1212 `build_summary()`
`summary.md`	`summary.json`의 사람이 읽는 버전	run_fdp_waf_stress.py:1215-1252 `build_summary_md()`
`worker_logs/<idx>/<phase>_<iter>/replay.log`	자식 lmcache 프로세스 stdout/stderr	`subprocess.Popen` redirect
`worker_logs/<idx>/<phase>_<iter>/records.jsonl`	per-record latency/failed	자식 `lmcache trace replay --jsonl-out`

WAF는 warmup 끝 → 측정 끝 구간만 본다 (= measurement_after - measurement_after_warmup). warmup 구간 SMART도 capture는 되지만 WAF 산출에는 안 들어감 (run_fdp_waf_stress.py:1144-1153).

2. `summary.json` 스키마 (메인 산출)

{
  "mode": "no_fdp" | "mixed" | "separated",
  "run_id": "20260611T...",
  "device_path": "/dev/ng0n1",
  "block_device_path": "/dev/nvme0n1",
  "worker_count": 5,
  "warmup_iterations": 2,
  "measurement_iterations": 8,
  "host_write_bytes_delta": 12345678,         ← nvme smart-log 기반
  "media_write_bytes_delta": 98765432,        ← vendor 명령 기반 (없으면 null)
  "waf": 7.99,                                 ← media_delta / host_delta
  "waf_status": "available" | "unavailable: ...",
  "workers": [
    {
      "name": "llama8b_chat_chunk256",
      "worker_index": 0,
      "worker_global_index": 0,
      "trace_path": "...",
      "base_offset_bytes": 0,
      "capacity_bytes": 17179869184,
      "slot_bytes": 524288,
      "fdp_data_ruh_ids": [0, 1],
      "fdp_metadata_ruh_ids": [2],
      "records_failed": 0,                    ← jsonl `failed:true` 카운트
      "exit_code": 0
    }
  ],
  "warnings": ["..."]
}

WAF 계산식

waf = media_write_bytes_delta / host_write_bytes_delta

host_write_bytes_delta = measurement_after.host_write_bytes − measurement_after_warmup.host_write_bytes
- source: nvme smart-log $NVME_NS --json → data_units_written (LBA/512B → bytes 변환)
media_write_bytes_delta = 동일하게 vendor 명령 기준 delta
- source: config measurement.vendor_media_write_command (사용자가 지정 — 단계 2 audit에서 식별 필요)

`waf_status` 분기

"available" — host>0 + media 둘 다 있음
"unavailable: host write counter missing" — nvme smart-log 실패
"unavailable: host write delta is zero" — 측정 구간에 host write 0 (workload 미동작)
"unavailable: media/NAND write counter missing" — vendor 명령 미설정 또는 실패

→ vendor counter 없을 때도 harness는 정상 종료, WAF 칸만 비고 host_write_bytes_delta는 그대로 채워진다.

3. `measurement_*.json` 스키마

각 시점별 (run_fdp_waf_stress.py:820-879):

{
  "label": "before_warmup" | "after_warmup" | "after_measurement",
  "enabled": true,
  "captured_at": "2026-06-11T...",
  "block_device_path": "/dev/nvme0n1",
  "warnings": [],

  "nvme_smart_log": { "json": { /* nvme smart-log -o json 전체 */ } },
  "host_write_bytes": 12345678,               ← 추출됨

  "vendor_media_write": { "stdout": "...", "json": {...} },
  "media_write_bytes": 98765432,              ← 추출 (실패시 null)

  "fdp_logs": {
    "stats": { /* xnvme log-fdp-stats --lsi 0x1 */ },
    "ruhu":  { /* xnvme log-ruhu --lsi 0x1 --limit 16 */ },
    "ruhs":  { /* xnvme fdp-ruhs --limit 16 */ }
  }
}

가용 지표 (시점 dump에서 추출 가능, summary에는 안 들어감)

nvme_smart_log 전체: data_units_written, data_units_read, host_read_commands, host_write_commands, controller_busy_time, power_cycles, unsafe_shutdowns, media_errors, percentage_used, available_spare, temperature
fdp_logs.stats: FDP write/read 통계 (NVMe spec FDP statistics log page)
fdp_logs.ruhu: per-RUH 사용량 (Reclaim Unit Handle Usage)
fdp_logs.ruhs: RUH 상태 (활성/비활성, GC 진행)

→ 단계 4에서 R1/R2/R3 비교 시 summary.json만 보지 말고 measurement_*.json의 fdp_logs.ruhu도 비교해야 RUH 분리 효과를 직접 본다.

4. `worker_logs/<idx>/<phase>_<iter>/records.jsonl` 스키마

per-record (= per lmcache trace replay operation), trace/init.py:394-404:

{"qualname": "StorageManager.put", "latency_ms": 0.123, "failed": false}
{"qualname": "StorageManager.get", "latency_ms": 5.678, "failed": false}

가용 지표 (별도 파싱 필요)

per-op latency 분포 — qualname별 p50/p90/p99/max
failure rate — qualname별 failed:true 비율 (summary.json은 worker별 합계만)
op mix — put vs get vs lookup 비율 (워크로드 검증)

harness 본체는 jsonl을 읽지 않는다. _count_failed_jsonl() (run_fdp_waf_stress.py:882-896)이 failed 카운트만 집계하고 latency는 무시한다. 단계 4에서 p99 read latency를 보려면 parse_results.py에 jsonl 파서를 추가해야 한다.

5. PLAN 단계 4 요구 지표 vs harness 가용성 매핑

PLAN.md 04_measure 단계가 요구하는 5개 지표와 PoC harness 가용성:

PLAN 요구 지표	harness 직접 제공	추출/별도 작업	비고
WAF	`summary.json::waf`	vendor counter 명령 식별 필요 (단계 2)	counter 없으면 `unavailable`
GC proxy (Media/Host write 비율)	`summary.json::waf` 자체가 그 비율	—	WAF와 동일
p99 read latency	❌	`records.jsonl` qualname=`get` 필터 후 `latency_ms` p99 계산	jsonl 파서 신설
TTFT	❌ (구조적 부재)	—	storage-level replay라 모델 안 돌아감 — 2차 tensormesh 필요
Hit ratio	❌	자식 lmcache의 Prometheus `/metrics` dump 필요 (현재 harness가 `--disable-metrics` 기본 ON, run_fdp_waf_stress.py:584-585)	`disable_metrics=false`로 켜고 별도 수집

1차에서 확정적으로 얻는 것

WAF (vendor counter 가용 시)
host write delta (vendor counter 없어도 항상)
per-RUH 사용량 분포 (fdp_logs.ruhu)
worker별 failure rate, exit code

1차에서 얻으려면 추가 작업

p99 latency: parse_results.py에 jsonl 파서 추가 (~30줄)
hit ratio: harness config의 global.disable_metrics: false + 자식 메트릭 endpoint dump 스크립트

1차에서 본질적으로 못 얻는 것

TTFT (모델 미실행) — 2차 tensormesh 단계로
실 워크로드 단의 hit ratio — 2차 tensormesh의 LMCache 메트릭으로

6. vendor media-write counter — 가장 큰 변수

PoC harness가 WAF를 산출하는 유일한 경로는 config의 measurement.vendor_media_write_command이다. 디바이스 벤더마다 명령이 다름:

벤더	후보 명령	출력에서 추출할 필드
Intel/Solidigm	`nvme intel smart-log-add $NVME_NS`	`nand_bytes_written` (raw count, 32MiB unit)
WDC	`nvme wdc vs-smart-add-log $NVME_NS`	`Physical NAND Bytes Written`
Samsung	`nvme samsung vs-smart-add-log $NVME_NS`	`physical_nand_bytes_written`
OCP-spec	`nvme ocp smart-add-log $NVME_NS`	`Physical Media Units Written` (16B unit)
일반 vendor log	`nvme get-log $NVME_NS --log-id=0xC0/0xCA --raw-binary`	벤더별 byte offset 파싱

→ smrc NVMe가 어느 벤더이고 어떤 명령이 가용한지 단계 2 media_write_counter_probe.txt에서 확인. 명령이 식별되면 PoC config에 다음과 같이 지정:

measurement:
  enabled: true
  collect_nvme_smart: true
  collect_fdp_logs: true
  vendor_media_write_command: "sudo nvme intel smart-log-add /dev/nvme0n1 -o json"

extract_media_write_bytes()가 JSON 또는 stdout 텍스트 양쪽에서 시도하므로 (run_fdp_waf_stress.py:842-853) JSON 출력이 안 되는 명령도 사용 가능.

7. 단계 4 runbook 영향

이 audit이 단계 4 측정 스크립트 작성에 주는 입력:

scripts: run_R1.sh / run_R2.sh / run_R3.sh 본체는 python -m benchmarks.fdp_waf_stress.run_fdp_waf_stress --mode <m> 한 줄로 충분. precondition·snapshot은 wrapping shell이 담당.
parse_results.py: summary.json의 4개 필드(waf, host_write_bytes_delta, media_write_bytes_delta, worker_count) 수집 + records.jsonl 파싱(p99 latency)을 둘 다 처리.
config: smrc 환경에 맞춘 config.smrc.yaml을 별도 작성 — device_path / block_device_path / vendor_media_write_command / windows.window_stride_bytes 4개를 단계 2 결과로 채움.
xnvme 설치 필요: harness가 fdp_logs 수집에 xnvme를 쓴다 (run_fdp_waf_stress.py:855-877). 단계 2 toolchain 체크에 xnvme 포함 (이미 PLAN §단계 2에 추가됨).

문서 출발점: 2026-06-11 — PoC harness 코드 직접 읽고 정리.

1. 산출 파일 목록​

2. summary.json 스키마 (메인 산출)​

WAF 계산식​

waf_status 분기​

3. measurement_*.json 스키마​

가용 지표 (시점 dump에서 추출 가능, summary에는 안 들어감)​

4. worker_logs/<idx>/<phase>_<iter>/records.jsonl 스키마​

가용 지표 (별도 파싱 필요)​

5. PLAN 단계 4 요구 지표 vs harness 가용성 매핑​

1차에서 확정적으로 얻는 것​

1차에서 얻으려면 추가 작업​

1차에서 본질적으로 못 얻는 것​

6. vendor media-write counter — 가장 큰 변수​

7. 단계 4 runbook 영향​