FDP 진행 상태

기준 문서: PLAN.md

이 파일은 plan 실행 중에 나온 문제점, 원인 분석, 해결 시도, 결과, 남은 리스크, 변경 파일을 남기는 작업일지다. 큰 raw 로그는 본문에 붙이지 않고 산출물 경로만 기록한다.

현재 작업

현재 단계: Stage 4 - PoC workload measurement 확대 실행 준비
담당 세션: Codex + 사용자 sudo shell 협업
대상 디바이스: /dev/nvme0n1 block namespace, /dev/ng0n1 raw generic namespace, controller /dev/nvme0, endgrp 1
마지막 블로커: mode별 raw-device window shift가 separated host write delta를 0으로 만든 것으로 확인됨
다음 행동: 기본 비교 run에서 mode window shift를 끄고 no_fdp / separated / mixed를 다시 측정

단계 상태

단계	상태	결과	핵심 산출물
0. 계획서 보관	완료	Codex 기준 plan/README/script 정리 완료	`PLAN.md`, `README.md`
1. PoC 브랜치 분석 + 문서화	완료	PoC 구조, ankit#1 포함 여부, FDP 구현 gap 분석 완료	`01_branch_audit/*.md`
2. smrc 환경 audit	완료	FDP 장치 확인, RUH 8개, target `/dev/nvme0n1` 확정	`02_smrc_env/smrc_env_report.md`, `02_smrc_env/raw/`
3. 빌드 + FDP sanity	완료	Rust raw_block extension 빌드, `/dev/ng0n1` direct write/read 성공	`03_build_test/sanity_smoke.md`, `/home/ny/fdp_build_test/`
4. 워크로드 측정	진행 중	replay 기능 검증 성공, SMART/FDP counter 파싱 성공. raw-device readback으로 실제 write 확인. after counter capture timing 보정 후 재측정 필요	`04_measure/summary.md`, `/home/ny/fdp_measure_status_probe/`
5. 개선 포인트 도출	대기	Stage 4의 유효 결과 필요	`05_design/` 예정

실행 기록

2026-06-12 - Stage 0 계획/문서 소유권 정리

결과:

fdp/ 문서는 초기에는 Claude 기준으로 작성되어 있었다.
주 실행자를 Codex로 맞추고, 현재 작업 위치를 /home/ny/work/fdp 기준으로 정리했다.

변경 파일:

PLAN.md: 단계별 주 실행자와 target/current path를 Codex 기준으로 정리.
README.md: 산출물 트리와 현재 진행 상태 반영.
FDP_for_LMCache.md: Codex 수행 흐름에 맞게 표현 정리.
Status.md: 기존 호환용 파일로 두고 canonical 파일을 status.md로 지정.

문제점 / 해결:

문제: plan 문서의 역할 분담이 실제 작업 주체와 달랐다.
조치: Codex가 직접 실행 가능한 항목과 user sudo shell이 필요한 항목을 분리했다.
결과: Stage 2 이후 실행 절차가 현재 세션 기준으로 일관되게 정리됐다.

단계 결과:

PASS. Stage 1/2 실행 기준 확보.

2026-06-12 - Stage 1 PoC 브랜치 분석 완료

결과:

PoC 저장소: /home/ny/work/LMCache-fdp-poc-src
브랜치: fdp-waf-agentic-replay-poc
실행에 사용한 커밋: 35784a3c
규모: 39 commits / 95 files / 15,678 added lines
ankit-sam/LMCache#1 포함 여부 결론: io_uring_cmd 인프라는 byte-identical로 흡수됐고, FDP API/정책은 PoC에서 독립적으로 확장됐다.

변경 파일:

01_branch_audit/01_codebase_map.md: PoC 변경 파일 분류와 호출 그래프.
01_branch_audit/02_ankit_sam_pr1_diff.md: ankit#1 patch/content 비교.
01_branch_audit/03_fdp_implementation_audit.md: FDP 7카테고리 구현/빈자리 audit.
01_branch_audit/04_harness_metrics.md: harness 지표 가용성 정리.
01_branch_audit/placement_policy_notes.md: placement_id 결정 경로 정리.
01_branch_audit/branch_diffstat.txt, 01_branch_audit/dev_base_commit.txt: raw audit output.

문제점 / 해결:

문제: ankit#1이 동일 SHA로 들어온 것이 아니라 squash/흡수 가능성이 있어서 단순 git log 비교만으로는 부족했다.
조치: patch-id, 핵심 hunk, content fingerprint 기준으로 판정했다.
결과: ankit#1의 io_uring_cmd 기반은 포함됐지만 PoC FDP policy/harness는 별도 구현으로 정리됐다.

단계 결과:

PASS. Stage 2/3에서 어떤 코드 경로를 빌드하고 검증할지 확정.

2026-06-12 - Stage 2 smrc 환경 audit 완료

결과:

최종 대상 SSD:
- SN: S77UNG0TC00101
- Controller: /dev/nvme0
- Block namespace: /dev/nvme0n1
- Generic char namespace: /dev/ng0n1
- NSID: 1
- Endurance Group ID: 1
FDP capability:
- nvme fdp configs /dev/nvme0 --endgrp-id=1 성공.
- Reclaim Unit Handles: 8
- RUH 0..7 존재, 초기 상태는 isolated.
- nvme fdp usage 기준 RUH 0..3은 Host Specified, RUH 4..7은 Unused.
Toolchain:
- rustc 1.75.0
- cargo 1.75.0
- python3 3.10.12
- liburing 2.0
- nvme-cli 2.15
- H100 표시됨

변경 파일:

02_smrc_env/precheck.sh: target /dev/nvme0n1//dev/ng0n1, --endgrp-id=1, vendor media counter와 xNVMe probe 보강.
02_smrc_env/smrc_env_report.md: raw output 기반 audit report.
02_smrc_env/raw/*: user precheck 결과 복사 및 보관.
README.md: target device를 /dev/nvme0n1로 정정.

문제점 / 해결:

문제: 처음 target을 SN S77UNG0TC00102(/dev/nvme1n1)로 추정했지만 user가 /dev/nvme0n1 사용을 지시했다.
조치: 모든 script/report/runbook target을 /dev/nvme0n1, /dev/ng0n1, /dev/nvme0로 수정했다.
결과: Stage 3/4 실행 target이 하나로 통일됐다.
문제: sudo nvme fdp configs /dev/nvme1 실행 시 endurance group identifier required가 발생했다.
원인: smrc nvme-cli FDP config 명령은 controller와 --endgrp-id가 필요했다.
조치: sudo nvme fdp configs /dev/nvme0 --endgrp-id=1 형식으로 수정했다.
결과: FDP config/status/stats 수집이 가능해졌다.
문제: Codex 세션에서 sudo password 입력이 불가능했다.
조치: Codex는 non-sudo 분석/문서/빌드를 수행하고, raw device write나 sudo nvme는 user sudo shell 실행 결과를 받아 파싱하는 방식으로 진행했다.
결과: Stage 2 raw output과 Stage 3 sanity result는 user shell 결과 기반으로 정리했다.
문제: vendor media/NAND write counter를 식별하지 못했다.
조치: precheck.sh에 smart-log-add, Samsung/OCP/WDC plugin 후보와 get-log 후보를 추가했다.
남은 리스크: vendor counter가 없으면 WAF는 unavailable; host write delta와 FDP stats 중심으로 1차 판단해야 한다.

단계 결과:

PASS. Stage 3 진행 가능.

2026-06-12 - Stage 3 빌드 + FDP 직접 sanity 완료

결과:

PoC checkout: /home/ny/work/LMCache-fdp-poc-src
Rust raw_block extension: maturin develop --release --manifest-path rust/raw_block/Cargo.toml 성공
FDP 직접 sanity:
- device: /dev/ng0n1
- RUH 후보: 0,1,2,3
- write 경로: RawBlockDevice.write_uring(..., dtype=2, dspec=0)
- readback 일치

증거:

/home/ny/fdp_build_test/sanity_write_chunk.log

write_uring offset=67108864 len=4096 dtype=2 dspec=0
readback_prefix=b'LMCache FDP sanity block\nLMCache'
readback_match=True
SANITY_STATUS=direct_write_attempted

변경 파일:

03_build_test/build_and_test.sh: NO_CUDA_EXT=1, INSTALL_LMCACHE_DEPS=0, target env 기본값.
03_build_test/sanity_write_chunk.py: direct FDP write/read sanity script.
03_build_test/sanity_smoke.md: Stage 3 결과, 실패 노트, 재실행 명령.
03_build_test/raw/*: sanity 로그와 before/after FDP stats.
/home/ny/work/LMCache-fdp-poc-src/rust/raw_block/src/lib.rs: Rust 1.75 호환 패치.

문제점 / 해결:

문제: full CUDA extension 빌드가 실패했다.
증상: system CUDA 11.5와 PyTorch wheel CUDA 12.8이 맞지 않았다.
조치: NO_CUDA_EXT=1로 CUDA extension build를 생략했다.
결과: Python package full extension은 미완료지만 raw_block Rust extension 검증은 진행 가능했다.
문제: full dependency install 중 disk full이 발생했다.
증상: [Errno 28] No space left on device.
조치: INSTALL_LMCACHE_DEPS=0로 pip install -e . --no-deps 경로를 사용했다.
결과: 필요한 PoC import와 raw_block build 중심으로 진행했다.
문제: smrc rustc가 1.75.0이라 usize::is_multiple_of()를 지원하지 않았다.
조치: rust/raw_block/src/lib.rs의 alignment check를 (value % align) == 0 방식으로 변경했다.
결과: Rust raw_block extension 빌드가 성공했다.
문제: /dev/ng0n1 권한이 crw------- root:root였다.
조치: user sudo shell에서 direct sanity를 실행했다.
결과: FDP direct write/read가 성공했다.
문제: sanity_stats_delta.diff가 비어 있었다.
원인: 4 KiB sanity write는 FDP stat counter granularity보다 작았다.
판단: stats delta는 보이지 않았지만 dtype=2, dspec=0 direct io_uring_cmd write/read path 자체는 성공했다.

단계 결과:

PASS. Stage 4 harness 검증으로 진행.

2026-06-12 - Stage 4 harness 준비 및 dry-run 완료

결과:

run_poc_harness.sh를 작성/수정한 뒤 DRY_RUN=1이 통과했다.
Dry-run output:
- no_fdp: /home/ny/work/fdp_measure_dry/R_no_fdp_20260612T093402
- separated: /home/ny/work/fdp_measure_dry/R_separated_20260612T093714
- mixed: /home/ny/work/fdp_measure_dry/R_mixed_20260612T093714
synthetic trace generation, config generation, 8-RUH remapping, replay command construction을 검증했다.

확인한 RUH 매핑:

no_fdp: FDP off, placement hint 없음.
separated: hot/small/random data [0,1], metadata [2]; cold/rag/large data [3,4], metadata [5]; metadata-heavy data [6,7].
mixed: 모든 worker가 data [0,1,3,4,6,7], metadata [2,5]를 공유.

변경 파일:

04_measure/run_poc_harness.sh: smrc target 기본값, system Python 경로, 8-RUH 매핑, CLI wrapper, DRY_RUN 처리.
04_measure/lmcache_cli_wrapper.py: PoC CLI 진입 wrapper.
04_measure/parse_results.py: summary.json + records.jsonl CSV parser.
04_measure/run_R0_precondition.sh: controller/endgrp-aware FDP stats 수집.
04_measure/runbook.md: Stage 4 실행 지침.
04_measure/summary.md: 현재 Stage 4 상태와 재실행 명령.
PLAN.md: Stage 4 dry-run 완료와 실제 실행 블로커 반영.

문제점 / 해결:

문제: PoC trace generator는 128 RUH 템플릿을 기대했지만 실제 SSD는 8 RUH였다.
조치: generator는 GENERATOR_RUH_COUNT=128로 유지하고, 실행 직전에 config mode를 실제 FDP_RUH_COUNT=8 매핑으로 다시 썼다.
결과: dry-run에서 모든 모드의 command construction이 성공했다.
문제: system Python에 필요한 일부 Python deps가 없었다.
조치: /home/ny/work/fdp/03_build_test/python_ext에 numba, llvmlite, numpy 등을 설치했다.
결과: generator/harness import가 가능해졌다.
문제: venv는 torch/runtime 의존성 때문에 harness subprocess에 부적합했다.
조치: PYTHON_BIN=/usr/bin/python3, PYTHONPATH=$RUST_EXT_PATH:$REPO를 사용했다.
결과: dry-run이 성공했다.
문제: R0 precondition script가 FDP stats를 namespace 대상으로 호출하고 있었다.
조치: sudo nvme fdp stats "$NVME_DEV" --endgrp-id="$FDP_ENDGRP_ID"로 수정했다.
결과: smrc nvme-cli 문법과 일치했다.

단계 결과:

부분 성공. dry-run은 성공했고, 실제 raw-device run은 sudo TTY가 필요했다.

2026-06-12 - Stage 4 첫 실제 실행 결과: 무효

실행:

user sudo shell에서 no_fdp, separated, mixed를 실행했다.
출력 루트: /home/ny/fdp_measure
각 mode가 2회씩 생성됐다.

결과:

/home/ny/fdp_measure에 6개 run directory가 생성됐다.
모든 run에서 worker_count는 9였다.
모든 worker의 exit_code는 1이었다.
records.jsonl은 없었다.
results_summary.csv 기준 records는 0이고 latency 컬럼은 비어 있었다.
WAF 상태는 unavailable: host write counter missing이었다.

실행 요약:

모드	실행 수	worker 상태	WAF 상태
`no_fdp`	2	모두 `exit_code=1`	unavailable: host write counter missing
`separated`	2	모두 `exit_code=1`	unavailable: host write counter missing
`mixed`	2	모두 `exit_code=1`	unavailable: host write counter missing

산출물:

/home/ny/fdp_measure/results_summary.csv
/home/ny/fdp_measure/R_*/summary.json
/home/ny/fdp_measure/R_*/worker_logs/*/measurement_0000/replay.log

트러블슈팅:

증상 1: worker exit_code=1
증거: 모든 replay.log 끝부분에 아래 오류가 있었다.

ModuleNotFoundError: No module named `lmcache.native_storage_ops`

원인: NO_CUDA_EXT=1 때문에 full setup extension build를 건너뛰었고, 이 과정에서 C++ pybind extension lmcache.native_storage_ops도 빌드되지 않았다. 그런데 LMCache CLI가 command registration 시점에 TTLLock/Bitmap을 import한다.
시도한 수정:
- 03_build_test/build_native_storage_ops.py 추가
- lmcache.native_storage_ops만 /home/ny/work/fdp/03_build_test/python_ext에 별도 빌드
- 생성된 .so를 /home/ny/work/LMCache-fdp-poc-src/lmcache/native_storage_ops.cpython-310-x86_64-linux-gnu.so로 복사
검증:

import lmcache.native_storage_ops as n
print(n.TTLLock)
print(n.Bitmap)

위 import는 harness와 같은 PYTHONPATH에서 성공했다.

증상 2: host_write_bytes가 null이었다.
증거: measurement_before.json에 아래 문구가 있었다.

smart-log: unrecognized option '--json'

원인: PoC는 nvme smart-log <dev> --json을 사용했지만, smrc nvme-cli 2.15는 --json 대신 -o json 또는 --output-format=json만 허용한다.
시도한 수정:
- /home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py를 nvme smart-log <dev> -o json로 패치
검증:
- 패치 후 DRY_RUN=1은 no_fdp에서 성공
- 실제 WAF 검증은 sudo 재실행이 필요

변경 파일:

03_build_test/build_native_storage_ops.py: native_storage_ops 전용 빌드 helper.
/home/ny/work/LMCache-fdp-poc-src/lmcache/native_storage_ops.cpython-310-x86_64-linux-gnu.so: 생성된 C++ extension을 package dir에 복사.
/home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py: SMART capture option을 --json에서 -o json으로 변경.
04_measure/summary.md: 실패한 run을 무효로 표시하고 retry command를 /home/ny/fdp_measure_retry로 이동.
04_measure/runbook.md: 실패 원인과 retry output path를 문서화.
PLAN.md: Stage 4 실제 실행 상태 갱신.

남은 리스크:

vendor media/NAND write counter는 아직 식별되지 않았다. 따라서 host write counter가 잡혀도 진짜 media-write WAF는 여전히 unavailable일 수 있다.
xNVMe는 수집 로그에 없다. FDP log collection은 여전히 불완전할 수 있다.
Codex는 이 세션에서 sudo 비밀번호를 직접 넣을 수 없으므로, 실제 sudo workload는 사용자 sudo shell이 필요하다.

단계 결과:

실패(측정값으로는 무효). 다만 문제 분석에는 유용했다. 수정 후 재시도가 필요했다.

2026-06-12 - Stage 4 재시도 준비

결과:

CLI import는 다음처럼 성공했다.

PYTHONPATH=/home/ny/work/fdp/03_build_test/python_ext:/home/ny/work/LMCache-fdp-poc-src \
  /usr/bin/python3 /home/ny/work/fdp/04_measure/lmcache_cli_wrapper.py --help

native_storage_ops import가 성공했다.
DRY_RUN=1 TRACE_SCALE=smoke MEASUREMENT_ITERATIONS=1 WARMUP_ITERATIONS=0 OUT=/home/ny/work/fdp_measure_retry_dry bash run_poc_harness.sh no_fdp도 성공했다.
Codex가 실제 sudo env ... run_poc_harness.sh no_fdp를 시도했지만 sudo prompt에서 막혔다.

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

사용자 sudo shell에서 실행할 다음 명령:

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

for mode in no_fdp separated mixed; do
  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_retry \
    bash run_poc_harness.sh "$mode"
done

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

단계 결과:

RETRY 준비 완료. 아직 유효한 Stage 4 측정은 없었다.

2026-06-15 - Stage 4 재시도 실제 실행 완료, replay 성공 / WAF counter 미완

실행:

사용자 sudo shell에서 /home/ny/fdp_measure_retry 대상으로 no_fdp, separated, mixed를 실행했다.
사용자가 parse_results.py 리다이렉션 줄바꿈 오류를 만났고, 한 줄 명령으로 수정해 results_summary.csv를 생성했다.

결과:

출력 루트: /home/ny/fdp_measure_retry
실행 디렉터리:
- R_no_fdp_20260615T032108
- R_separated_20260615T032127
- R_mixed_20260615T032145
모든 mode가 replay를 완료했다.
- workers: 9
- records: 179
- worker 종료 실패: 0
- record 실패: 0
native_storage_ops 문제는 해결되었다.

지표:

모드	records	write p50 ms	write p99 ms	all p99 ms	FDP HBMW delta	WAF 상태
`no_fdp`	179	0.077	0.744	0.705	0	unavailable: host write counter missing
`separated`	179	0.060	0.612	0.546	0	unavailable: host write counter missing
`mixed`	179	0.065	1.047	0.852	442,368	unavailable: host write counter missing

해석:

기능 검증 기준으로는 PoC replay가 성공했다.
다만 host-write counter가 여전히 null이어서 이 결과는 유효한 WAF 측정이 아니다.
이번 1-run smoke에서는 separated가 no_fdp와 mixed보다 p99가 낮아 보였지만, 샘플이 너무 작고 precondition도 적용하지 않았으므로 참고 신호일 뿐이다.

문제점 / 해결:

증상: waf_status = unavailable: host write counter missing
증거: measurement_before.json와 measurement_after.json에 다음이 있었다.

command: nvme smart-log /dev/nvme0n1 -o json
stderr: Invalid output format

원인: 이 smrc nvme smart-log는 일반 출력은 지원하지만 JSON 출력을 거부한다.
실행 후 적용한 수정:
- run_fdp_waf_stress.py가 -o json 실패 시 일반 nvme smart-log <device>로 재시도하도록 패치
- 일반 텍스트의 Data Units Written : <N> (...) 라인을 파싱하는 코드 추가
- run_poc_harness.sh 외부 SMART 캡처를 outer_smart_before.txt/outer_smart_after.txt의 일반 텍스트로 변경
- run_R0_precondition.sh의 SMART 캡처도 동일하게 변경

변경 파일:

/home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py: SMART JSON fallback 및 Data Units Written 파서 추가.
04_measure/run_poc_harness.sh: 외부 SMART 캡처를 일반 텍스트로 변경.
04_measure/run_R0_precondition.sh: SMART 캡처를 일반 텍스트로 변경.
04_measure/summary.md: retry 결과 표와 해석 반영.

남은 리스크:

vendor media/NAND write counter는 여전히 식별되지 않았다.
현재 smoke는 R0 precondition이 없고 측정 iteration도 1회뿐이다.
FDP stats는 mixed에서만 442,368 HBMW bytes 정도 움직였는데, GC/WAF 결론을 내리기에는 너무 작다.

단계 결과:

부분 성공. replay 기능 검증은 성공했고, WAF/host counter는 SMART fallback 적용 후 재실행이 필요했다.

2026-06-15 - Stage 4 SMART 재시도 완료, host counter 파싱 성공 / delta 0

실행:

사용자 sudo shell에서 /home/ny/fdp_measure_smart_retry 대상으로 no_fdp, separated, mixed를 실행했다.
사용자가 /home/ny/fdp_measure_smart_retry/results_summary.csv를 생성했다.

결과:

출력 루트: /home/ny/fdp_measure_smart_retry
실행 디렉터리:
- R_no_fdp_20260615T033017
- R_separated_20260615T033036
- R_mixed_20260615T033054
모든 mode가 replay를 완료했다.
- workers: 9
- records: 179
- worker 종료 실패: 0
- record 실패: 0
SMART normal text fallback이 정상 동작했다.
- nvme smart-log /dev/nvme0n1 returncode 0
- Data Units Written을 파싱해 host_write_bytes를 채웠다.

지표:

모드	records	write p50 ms	write p99 ms	all p99 ms	WAF 상태
`no_fdp`	179	0.072	0.403	0.398	unavailable: host write delta is zero
`separated`	179	0.107	0.764	0.743	unavailable: host write delta is zero
`mixed`	179	0.063	0.340	0.332	unavailable: host write delta is zero

해석:

SMART capture 문제는 해결됐다. 이제 normal SMART 출력의 Data Units Written을 읽을 수 있다.
다만 smoke trace가 너무 작아서 before/after Data Units Written 값이 같았고, FDP stats delta도 모두 0이었다.
따라서 이번 결과는 기능 검증으로는 성공이지만 WAF 측정으로는 아직 부족하다.
PoC README 기준으로도 smoke는 quick validation용이고, WAF testing에는 stress scale을 사용해야 한다.

다음 실행:

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

for mode in no_fdp separated mixed; do
  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=0 \
    MEASUREMENT_ITERATIONS=1 \
    OUT=/home/ny/fdp_measure_stress \
    bash run_poc_harness.sh "$mode"
done

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

남은 리스크:

vendor media/NAND write counter는 아직 식별되지 않았다. 따라서 host write delta가 잡혀도 true media-write WAF는 계속 unavailable일 수 있다.
stress는 smoke보다 훨씬 많은 write를 발생시킨다. target은 계속 /dev/nvme0n1이다.

단계 결과:

부분 성공. SMART host-write 파싱과 replay 기능 검증은 성공했고, WAF 신호 확인은 stress scale 재실행이 필요하다.

2026-06-15 - Stage 4 stress 실행 완료, replay 성공 / device counter delta 0

실행:

사용자 sudo shell에서 /home/ny/fdp_measure_stress 대상으로 TRACE_SCALE=stress 실행.
no_fdp, separated, mixed 모두 실행했고 results_summary.csv를 생성했다.

결과:

출력 루트: /home/ny/fdp_measure_stress
실행 디렉터리:
- R_no_fdp_20260615T033900
- R_separated_20260615T033935
- R_mixed_20260615T034007
모든 mode가 replay를 완료했다.
- workers: 9
- records: 27,240
- worker 종료 실패: 0
- record 실패: 0

지표:

모드	records	write p50 ms	write p99 ms	all p99 ms	WAF 상태
`no_fdp`	27,240	0.079	0.654	0.644	unavailable: host write delta is zero
`separated`	27,240	0.089	0.770	0.767	unavailable: host write delta is zero
`mixed`	27,240	0.073	0.757	0.742	unavailable: host write delta is zero

해석:

stress trace 자체는 생성/실행됐다. trace summary 기준 예상 store bytes는 워크로드별로 수 GiB~수십 GiB 규모다.
그런데 SMART Data Units Written, FDP HBMW/MBMW/MBE가 모두 움직이지 않았다.
따라서 현재 결과도 WAF 측정으로는 무효다.
원인은 trace replay가 StorageManager.reserve_write/finish_write를 호출한 직후 프로세스를 닫으면서, 비동기 StoreController의 L2 raw-block store 작업이 device까지 drain되기 전에 종료되는 구조로 추정된다.

적용한 수정:

lmcache trace replay에 --settle-seconds 옵션 추가.
replay dispatch 완료 후 StorageManager.close() 전에 지정한 시간만큼 대기하도록 변경.
run_poc_harness.sh에 REPLAY_SETTLE_SECONDS env 추가.
PoC harness가 생성하는 worker command에 --settle-seconds를 넣도록 run_fdp_waf_stress.py 수정.
dry-run으로 worker command에 --settle-seconds 3.0이 들어가는 것 확인.

변경 파일:

/home/ny/work/LMCache-fdp-poc-src/lmcache/cli/commands/trace/__init__.py: --settle-seconds 인자와 close 전 대기 추가.
/home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py: replay command에 --settle-seconds 전달.
04_measure/run_poc_harness.sh: REPLAY_SETTLE_SECONDS env를 generated config에 반영.
04_measure/summary.md: stress 결과와 해석 추가.

다음 실행:

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

for mode in no_fdp separated mixed; do
  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=0 \
    MEASUREMENT_ITERATIONS=1 \
    REPLAY_SETTLE_SECONDS=30 \
    OUT=/home/ny/fdp_measure_stress_settle \
    bash run_poc_harness.sh "$mode"
done

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

단계 결과:

부분 성공. stress replay 기능은 성공했지만 device write가 관측되지 않았고, settle wait 적용 후 재실행이 필요하다.

2026-06-15 - Stage 4 stress delta 0 원인 재분석: raw-block slot 크기 오류 확인

결과:

/home/ny/fdp_measure_stress/R_separated_20260615T033935/worker_logs/000/measurement_0000/replay.log에서 raw-block store 실패가 확인됐다.
대표 오류:

RawBlockCore write failed ... Aligned payload 4194304 exceeds slot capacity
Store task ... failed

원인:

synthetic trace generator와 workload config의 slot_bytes는 object payload 크기로 쓰이고 있었다.
RawBlockCore의 slot_bytes는 header 영역까지 포함한 물리 slot 크기다.
기존 harness는 payload와 같은 값을 raw-block slot_bytes로 넘겼고, 기본 header_bytes=4096 때문에 payload <= slot_bytes - header_bytes 조건을 만족하지 못했다.
따라서 replay operation 자체는 records_failed=0으로 보였지만, L2 raw-block store task는 내부에서 실패했고 실제 write_uring device write까지 내려가지 않았다.

조치:

/home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py의 build_l2_adapter()를 수정했다.
workload slot_bytes는 payload 크기로 유지한다.
raw-block adapter에 넘기는 slot_bytes는 worker.slot_bytes + header_bytes로 계산한다.
adapter JSON에 header_bytes도 명시한다.

검증:

bash -n /home/ny/work/fdp/04_measure/run_poc_harness.sh 통과.
python3 -m py_compile .../run_fdp_waf_stress.py 통과.
dry-run에서 4 MiB payload workload의 adapter slot_bytes가 4194304에서 4198400으로 보정되는 것을 확인했다.

단계 결과:

원인 확인 및 패치 완료. sudo shell에서 stress 재실행 필요.

2026-06-15 - Stage 4 slotfix stress 재실행 결과: slot 오류 해결, counter는 여전히 0

실행:

출력 루트: /home/ny/fdp_measure_stress_slotfix
모드: no_fdp, separated, mixed
조건: TRACE_SCALE=stress, WARMUP_ITERATIONS=0, MEASUREMENT_ITERATIONS=1, REPLAY_SETTLE_SECONDS=30

결과:

모드	records	write p99 ms	all p99 ms
`no_fdp`	27,240	2.176	2.118
`separated`	27,240	0.795	0.781
`mixed`	27,240	0.487	0.468

확인한 점:

새 command에는 보정된 raw-block slot 크기가 들어갔다. 예: 4 MiB payload workload의 adapter slot_bytes=4198400.
--settle-seconds 30.0도 worker command와 replay log에 반영됐다.
이전 블로커였던 Aligned payload ... exceeds slot capacity, RawBlockCore write failed, Store task ... failed는 재실행 로그에서 발견되지 않았다.
대신 27개 worker replay log 전체에서 Failed to batched allocate ... no enough memory 경고가 총 12,930건 발견됐다.

판단:

slot sizing 문제는 해결됐다.
하지만 reserve_write가 예외 없이 끝나도 실제로는 L1 allocation이 실패해 빈/부분 reserve가 발생할 수 있다.
현재 records_failed=0은 trace dispatcher 관점의 성공일 뿐, L2 raw-block store가 충분히 수행됐다는 증거가 아니다.
host/FDP counter가 계속 0이므로 아직 유효한 WAF/FDP 결과로 해석할 수 없다.

추가 조치:

/home/ny/work/LMCache-fdp-poc-src/lmcache/cli/commands/trace/__init__.py에 replay 종료 직전 storage_manager_status_before_close.json을 남기는 관측 패치를 추가했다.
다음 재실행에서 L1 상태, StoreController pending/in-flight, RawBlockL2Adapter completed store count, RawBlockCore used slots를 직접 확인한다.
별도로 raw device의 예상 data slot offset에서 LMCBLK01 header readback을 확인하면 실제 device write 여부를 더 직접적으로 판정할 수 있다.

단계 결과:

부분 진전. raw-block slot 오류는 해결됐지만 device write 관측은 아직 실패.

2026-06-15 - Stage 4 status probe 결과: raw-block core는 슬롯을 채웠지만 device counter는 0

실행:

출력 루트: /home/ny/fdp_measure_status_probe
모드: separated
조건: TRACE_SCALE=stress, WARMUP_ITERATIONS=0, MEASUREMENT_ITERATIONS=1, REPLAY_SETTLE_SECONDS=30

결과:

results_summary.csv:
- records: 27,240
- failures: 0
- host write delta: 0
- FDP HBMW/MBMW/MBE delta: 0
각 worker에 storage_manager_status_before_close.json 생성 확인.

worker 상태 요약:

worker	indexed_key_count	max_slots	next_slot	metadata_dirty_total	raw slot_bytes
000	239	239	239	1,937	4,198,400
001	239	239	239	2,073	4,198,400
002	61	61	61	451	33,558,528
003	59	59	59	451	16,781,312
004	59	59	59	451	16,781,312
005	479	479	479	3,633	2,101,248
006	479	479	479	1,985	2,101,248
007	479	479	479	2,073	2,101,248
008	446	446	446	12,980	1,052,672

판단:

RawBlockCore 관점에서는 모든 worker의 data slot window가 가득 찼다.
따라서 단순히 raw-block adapter가 전혀 실행되지 않았다는 가설은 약하다.
그러나 SMART Data Units Written, host_write_commands, FDP HBMW/MBMW/MBE가 모두 변하지 않았다.
즉 현재 모순은 “raw-block core 내부 상태는 write 성공처럼 보이지만 NVMe device counter는 움직이지 않는다”이다.

다음 확인:

counter가 아니라 실제 device offset readback으로 판정해야 한다.
worker 000의 첫 data slot header 예상 offset:
- base: 2199023255552
- data_base: 2199090364416
- header magic: LMCBLK01 예상
user sudo shell에서 block device readback 또는 raw_block readback script로 해당 offset에 header가 실제 존재하는지 확인한다.

2026-06-15 - raw-device readback으로 실제 write 확인

사용자 확인 결과:

dd if=/dev/nvme0n1 bs=4096 skip=536887296 count=1 status=none | xxd -l 64
00000000: 4c4d 4342 4c4b 3031 ...

판정:

4c4d 4342 4c4b 3031은 ASCII LMCBLK01이다.
따라서 raw-block header가 실제 /dev/nvme0n1에 기록됐다.
이전 가설인 “raw block write 자체가 안 됨”은 기각한다.

추가 counter 확인:

Data Units Written: 3482237610
host_write_commands: 123827451248
HBMW: 9342311202816
MBMW: 10561063010304
MBE: 10948945379328

status probe의 captured after 값과 비교:

Data Units Written delta: 336,209 units, 약 172,139,008,000 bytes
host_write_commands delta: 713,032
HBMW delta: 172,139,261,952 bytes
MBMW delta: 180,906,201,088 bytes
MBE delta: 179,381,993,472 bytes

판단:

실제 write와 controller counter 증가는 확인됐다.
harness의 measurement_after.json과 outer_*_after.txt가 counter update보다 이른 시점에 캡처된 것으로 보인다.

조치:

/home/ny/work/fdp/04_measure/run_poc_harness.sh에 POST_MEASURE_SETTLE_SECONDS 기본값 120초를 추가했다.
outer SMART/FDP after capture 전에 sleep "$POST_MEASURE_SETTLE_SECONDS"를 수행한다.
/home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py도 measurement_after.json 캡처 전에 global.post_measure_settle_seconds만큼 대기하도록 수정했다.
dry-run에서 post_measure_settle_seconds와 보정된 raw-block slot_bytes, --settle-seconds가 command에 반영되는 것을 확인했다.

다음 실행:

separated 단일 모드부터 POST_MEASURE_SETTLE_SECONDS=180 정도로 재측정한다.

2026-06-15 - counter probe 성공: after settle 후 SMART/FDP delta 관측

실행:

출력 루트: /home/ny/fdp_measure_counter_probe
모드: separated
조건: TRACE_SCALE=stress, WARMUP_ITERATIONS=0, MEASUREMENT_ITERATIONS=1, REPLAY_SETTLE_SECONDS=30, POST_MEASURE_SETTLE_SECONDS=180

결과:

records: 27,240
failures: 0
host write delta: 40,058,880,000 bytes
FDP HBMW delta: 40,058,802,176 bytes
FDP MBMW delta: 40,692,744,192 bytes
FDP MBE delta: 53,150,220,288 bytes
WAF status: unavailable: media/NAND write counter missing

outer counter 확인:

SMART Data Units Written: 3482237610 -> 3482315850
SMART host_write_commands: 123827451248 -> 123827615161
FDP HBMW: 9342311202816 -> 9382370004992
FDP MBMW: 10561063010304 -> 10601755754496
FDP MBE: 10948945379328 -> 11002095599616

판정:

POST_MEASURE_SETTLE_SECONDS 적용 후 harness summary에 host/FDP counter delta가 정상 반영됐다.
Stage 4 측정 경로는 이제 유효하다.
단, vendor media/NAND write counter가 없어 WAF 자체는 아직 계산 불가다.
다음은 같은 조건으로 no_fdp, separated, mixed 3모드 측정을 수행해 host/FDP counter와 latency를 비교한다.

2026-06-15 - 3모드 valid 후보 실행 결과: 비교용으로는 보류

실행:

출력 루트: /home/ny/fdp_measure_3mode_valid
모드: no_fdp, separated, mixed
조건: TRACE_SCALE=stress, WARMUP_ITERATIONS=0, MEASUREMENT_ITERATIONS=1, REPLAY_SETTLE_SECONDS=30, POST_MEASURE_SETTLE_SECONDS=180

결과 요약:

모드	records	summary host delta	FDP HBMW delta	write p99 ms	판단
`no_fdp`	27,240	0	45,102,292,992	0.487	내부 after capture가 빨라 summary host delta가 0
`separated`	27,240	0	0	0.887	이전 `counter_probe`와 key/run-id 중복 가능성
`mixed`	27,240	89,877,504,000	89,877,598,208	2.473	counter 정상 관측

추가 확인:

no_fdp의 outer SMART/FDP after는 증가했다. 즉 실제 write는 있었지만 내부 measurement_after.json이 counter 반영보다 빠르게 캡처됐다.
separated는 이전 /home/ny/fdp_measure_counter_probe와 같은 PoC 내부 run_id=waf001, 같은 mode라 cache salt와 raw-block key가 중복됐다. raw-block metadata가 기존 key를 로드해 새 write가 줄어들 수 있다.

조치:

/home/ny/work/fdp/04_measure/run_poc_harness.sh에서 PoC --run-id를 shell run directory id(R_<mode>_<timestamp>)로 넘기도록 수정했다.
POST_MEASURE_SETTLE_SECONDS 기본값을 360초로 늘렸다.
wrapper의 outer after capture 전 추가 sleep은 제거했다. 내부 Python harness가 after counter settle을 담당한다.
dry-run에서 poc_run_id=R_separated_...와 replay salt prefix가 고유 run id를 포함하는 것을 확인했다.
추가로 모드별 raw-device window가 충돌하지 않도록 windows.start_offset_bytes를 mode별로 shift한다.
- no_fdp: 기본 offset
- separated: 기본 offset + 64 GiB
- mixed: 기본 offset + 128 GiB
dry-run에서 separated worker 0 base offset이 2199023255552에서 2267742732288로 이동하는 것을 확인했다.

판정:

/home/ny/fdp_measure_3mode_valid는 최종 3모드 비교 결과로 사용하지 않는다.
고유 run id + POST_MEASURE_SETTLE_SECONDS=360으로 재실행 필요.

문제 요약

문제	증상	원인	해결/우회	결과
잘못된 FDP 타깃 후보	처음 `/dev/nvme1n1`를 고려함	사용자가 `/dev/nvme0n1`을 확정	모든 script/doc를 `/dev/nvme0n1` + `/dev/ng0n1`로 수정	해결
`nvme fdp configs` 오류	`endurance group identifier required`	smrc nvme-cli는 `--endgrp-id` 필요	`/dev/nvme0 --endgrp-id=1` 사용	해결
Codex sudo 제한	`sudo: a terminal is required`	API 세션에 sudo 비밀번호 TTY가 없음	사용자가 sudo 명령 실행, Codex는 결과를 파싱	계속되는 제약
CUDA extension build 실패	CUDA 11.5 vs PyTorch CUDA 12.8 불일치	system/toolchain mismatch	`NO_CUDA_EXT=1`	raw_block 검증은 성공, full extension은 생략
deps install 중 disk full	`[Errno 28] No space left on device`	root FS 공간 부족	`INSTALL_LMCACHE_DEPS=0`, 필요한 target deps만 설치	우회
Rust build 실패	`usize::is_multiple_of` 사용 불가	rustc 1.75 API 미지원	`% align == 0`으로 교체	해결
Stage 3 stats delta 비어 있음	`sanity_stats_delta.diff` empty	4 KiB smoke가 counter granularity보다 작음	readback + dspec path를 sanity 증거로 사용	수용
Stage 4 worker 실패	모든 worker `exit_code=1`	`lmcache.native_storage_ops` 누락	C++ extension을 별도 빌드해 `.so` 복사	해결, 재시도 필요
Stage 4 host counter 문제	`smart-log: unrecognized option '--json'`	nvme-cli 2.15 옵션 불일치	`-o json`으로 패치	해결, 재시도 필요
Stage 4 host counter 추가 문제	`Invalid output format` for `-o json`	smrc `nvme smart-log`가 JSON을 거부	일반 텍스트 SMART로 fallback 후 `Data Units Written` 파싱	2026-06-15 이후 해결, 재시도 필요
Stage 4 host delta 0	`host_write_bytes_delta=0`	`smoke` workload가 SMART/FDP counter를 움직이기엔 너무 작음	`TRACE_SCALE=stress` 또는 duration 기반 replay 사용	열려 있음
Stage 4 stress delta 0	stress에서도 host/FDP delta가 0	raw-block slot 크기 계산 오류로 L2 store task가 `Aligned payload ... exceeds slot capacity` 실패	raw-block adapter `slot_bytes = payload_slot + header_bytes`로 보정	패치 완료, 재실행 필요
Stage 4 slotfix stress delta 0	slot 오류 제거 후에도 host/FDP delta가 0	L1 allocation 실패가 대량 발생하고, 현재 summary는 L2 store 성공량을 보여주지 못함	`StorageManager.report_status()` 덤프 추가, raw-device header readback 필요	진행 중
after counter capture timing	실제 device에는 `LMCBLK01`가 있고 수동 확인 시 SMART/FDP counter도 증가했지만 harness summary delta는 0	controller counter 반영보다 harness after capture가 빠름	`POST_MEASURE_SETTLE_SECONDS` 추가	재측정 필요
counter probe	after settle 이후 counter delta 필요	기존 after capture가 너무 빨랐음	`POST_MEASURE_SETTLE_SECONDS=180`으로 재실행	해결, 3모드 비교 필요
3모드 후보 결과 보류	`separated` delta 0, `no_fdp` summary host delta 0	PoC 내부 `run_id=waf001` 재사용, 180초 internal settle 부족	고유 `--run-id` 전달, `POST_MEASURE_SETTLE_SECONDS=360`	패치 완료, 재실행 필요
mode window 충돌	순차 실행 시 mode들이 같은 raw-device window를 덮어씀	generated config의 `windows.start_offset_bytes`가 mode별로 같음	mode별 64 GiB offset shift 추가	패치 완료, 그러나 `separated` delta 0 원인으로 확인되어 기본값에서 비활성화
WAF가 계속 unavailable일 가능성	media/NAND counter 없음	vendor command 미식별	host writes/FDP stats를 먼저 비교하고 vendor counter를 계속 탐색	열려 있음

2026-06-15 - mode window shift 원인 확인

실행:

separated만 단독 재실행
출력 루트: /home/ny/fdp_measure_sep_noshift
조건: 기존 stress 측정과 동일, 단 DISABLE_MODE_WINDOW_SHIFT=1

결과:

run: /home/ny/fdp_measure_sep_noshift/R_separated_20260615T081624
host_write_bytes_delta = 166,782,464,000
waf_status = unavailable: media/NAND write counter missing

판정:

separated가 0으로 나온 직접 원인은 allocator warning 자체가 아니었다.
같은 workload/settle 조건에서도 mode별 raw-device window shift를 끄면 separated host delta가 정상적으로 돌아왔다.
따라서 +64 GiB shifted raw window가 separated delta 0의 원인으로 판단된다.

조치:

run_poc_harness.sh 기본값을 DISABLE_MODE_WINDOW_SHIFT=1로 변경했다.
runbook.md에 mode window shift는 진단용 실험이며 기본 비교 run에서는 끄는 것으로 정리했다.

2026-06-15 - 최종 3모드 동일조건 비교 결과 확보

실행:

출력 루트: /home/ny/fdp_measure_3mode_final
모드: no_fdp, separated, mixed
공통 조건:
- TRACE_SCALE=stress
- WARMUP_ITERATIONS=0
- MEASUREMENT_ITERATIONS=1
- REPLAY_SETTLE_SECONDS=30
- POST_MEASURE_SETTLE_SECONDS=360
- 기본 DISABLE_MODE_WINDOW_SHIFT=1

결과 요약:

모드	run dir	records	host write delta	FDP HBMW delta	write p99 ms	판정
`no_fdp`	`R_no_fdp_20260615T083105`	27,240	385,622,528,000	385,622,347,776	1.353	유효
`separated`	`R_separated_20260615T083813`	27,240	198,493,184,000	198,492,884,992	3.357	유효
`mixed`	`R_mixed_20260615T084519`	27,240	43,859,968,000	43,860,094,976	1.290	유효

추가 확인:

outer SMART Data Units Written와 internal measurement_after - measurement_after_warmup delta가 각 모드에서 일치했다.
outer FDP HBMW delta도 내부 host delta와 같은 방향으로 증가했다.
처음 생성된 /home/ny/fdp_measure_3mode_final/results_summary.csv는 0-byte였지만, run 산출물은 정상이었고 parse_results.py 재실행으로 CSV를 다시 생성해 확인했다.

판정:

이번 /home/ny/fdp_measure_3mode_final은 Stage 4의 첫 유효한 동일조건 3모드 비교 결과다.
separated는 더 이상 host_write_bytes_delta=0이 아니며, 같은 조건 비교가 가능하다.
다만 이번 PoC workload에서는 host writes가 no_fdp > separated > mixed 순으로 나왔다.
따라서 "separated가 가장 낮아야 한다"는 초기 기대는 아직 입증되지 않았다.

2026-06-15 - 반복 실험 준비

유효한 1차 결과는 확보했지만, 아직 단일 batch라 재현성은 미검증 상태다.
04_measure/run_repeated_trials.sh를 추가했다.
- 동일 조건 3모드를 trial 단위로 반복 실행한다.
- 기본 REPEATS=3, ORDER_STRATEGY=rotate.
- 각 trial마다 results_summary.csv를 생성한다.
04_measure/summarize_repeated_trials.py를 추가했다.
- batch 전체 per-run 결과와 mode별 평균/표준편차를 하나의 CSV로 낸다.
다음 실행은 /home/ny/fdp_measure_repeats/batch_* 구조로 저장하고, mode별 평균과 표준편차를 기준으로 재현성을 판단한다.

2026-06-15 - vendor media-write counter 확인

/home/ny/work/fdp/02_smrc_env/raw/media_write_counter_probe.txt에서 OCP SMART log가 동작하는 것을 확인했다.
유효 후보:
- nvme ocp smart-add-log /dev/nvme0n1 -o json
- JSON field: "Physical media units written": {"hi": 0, "lo": 2114796921614336}
LMCache-fdp-poc-src/benchmarks/agentic_mp_trace/replay_region_churn.py도 OCP log page 0xC0의 첫 16바이트를 physical_media_write_bytes로 사용하고 있다.
benchmarks/fdp_waf_stress/run_fdp_waf_stress.py의 extract_media_write_bytes()에 OCP JSON/text 형식 파싱을 추가했다.
다음 정식 WAF run에서는 아래 env를 넣는다.

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

기존 /home/ny/fdp_measure_3mode_final은 vendor command 없이 실행됐으므로 정식 WAF는 여전히 unavailable이다. OCP command를 넣은 재실행부터 media_write_bytes_delta와 waf가 산출된다.

2026-06-15 - WAF probe 1 set

출력 루트: /home/ny/fdp_measure_waf_probe
조건: 기존 stress 3모드와 동일, 단 VENDOR_MEDIA_WRITE_COMMAND="nvme ocp smart-add-log /dev/nvme0n1 -o json" 추가.
결과:

모드	host write delta	media write delta	WAF	status	판정
`no_fdp`	45,222,400,000	45,940,211,712	1.0158729239	available	WAF 산출 성공
`separated`	44,993,024,000	45,707,427,840	1.0158781023	available	WAF 산출 성공
`mixed`	0	0	null	unavailable: host write delta is zero	이번 set에서는 무효

결론:
- OCP vendor media-write command와 parser 보정은 정상 동작한다.
- no_fdp, separated에서 정식 WAF가 계산됐다.
- mixed는 measurement 구간의 host/media counter가 모두 0이라 비교 결과로 쓰면 안 된다.
- 정식 3모드 WAF 비교를 얻으려면 mixed 포함 batch를 다시 실행해야 한다.

2026-06-15 - R0 precondition 보강

원문 PoC 문서의 평가 고려사항은 clean state에서 WAF가 잘 안 보일 수 있으므로 sustained-state preconditioning을 권장한다.
기존 run_R0_precondition.sh는 namespace 앞 16GiB만 sequential fill했다.
- 문제: PoC harness raw window는 기본적으로 2199023255552 bytes, 즉 2TiB 부근에서 시작한다.
- 따라서 기존 R0는 실제 측정 window를 precondition하지 못했다.
run_R0_precondition.sh를 보강했다.
- destructive 실행에는 R0_CONFIRM=YES 필요.
- 기본 precondition span을 harness 기본 window 시작 offset 2199023255552 bytes로 설정.
- 기본 span size를 32 GiB로 설정.
- fio sequential fill 후 random overwrite pass를 수행.
- SMART/FDP/vendor counter를 before/after 단계별로 캡처.
dry-run 검증:
- bash -n run_R0_precondition.sh 통과.
- DRY_RUN=1 R0_CONFIRM=YES PRECONDITION_SIZE_GB=1 ...에서 blkdiscard, sequential fio, random fio command 구성이 확인됐다.

plan 시작 이후 변경 파일

주요 fdp/ 산출물:

PLAN.md: Codex 소유권, target 수정, stage 진행, 블로커.
README.md: 산출물 트리와 현재 target.
status.md: canonical 실행 상태.
Status.md: 호환용 stub.
FDP_for_LMCache.md: Codex 중심 표현 정리.
01_branch_audit/*.md: branch audit 문서.
02_smrc_env/precheck.sh: FDP/env audit script.
02_smrc_env/smrc_env_report.md: smrc target/capability report.
03_build_test/build_and_test.sh: build/sanity 자동화.
03_build_test/sanity_write_chunk.py: 직접 FDP sanity.
03_build_test/sanity_smoke.md: Stage 3 최종 상태.
03_build_test/build_native_storage_ops.py: native_storage_ops 전용 빌드 helper.
04_measure/run_R0_precondition.sh: destructive precondition script, FDP stats 호출 수정.
04_measure/run_poc_harness.sh: smrc defaults가 들어간 PoC harness wrapper.
04_measure/lmcache_cli_wrapper.py: CLI 진입 wrapper.
04_measure/parse_results.py: 결과 parser.
04_measure/runbook.md: Stage 4 runbook.
04_measure/summary.md: Stage 4 상태와 retry 명령.

PoC repo 로컬 변경:

/home/ny/work/LMCache-fdp-poc-src/rust/raw_block/src/lib.rs: Rust 1.75 alignment 호환 패치.
/home/ny/work/LMCache-fdp-poc-src/benchmarks/fdp_waf_stress/run_fdp_waf_stress.py: nvme smart-log -o json 호환 패치와 SMART text fallback 파서.
/home/ny/work/LMCache-fdp-poc-src/lmcache/native_storage_ops.cpython-310-x86_64-linux-gnu.so: CLI replay용 생성 extension.

생성된 결과 디렉터리:

/home/ny/fdp_build_test/: Stage 3 direct sanity 로그.
/home/ny/work/fdp_measure_dry/: Stage 4 dry-run 검증.
/home/ny/fdp_measure/: 첫 실제 실행의 무효 결과 보관.
/home/ny/work/fdp_measure_retry_dry/: 패치 후 dry-run 검증.
/home/ny/fdp_measure_retry/: 2026-06-15 기능 replay 성공 결과.
/home/ny/fdp_measure_smart_retry/: SMART text fallback 검증 결과. replay 성공, host delta는 0.
/home/ny/fdp_measure_stress/: stress replay 성공, device counter delta는 0.

Stage 5 메모

file backend FDP는 PoC에 아직 구현되지 않았다.
PoC에는 ankit#1 스타일의 fetch_fdp_status RUH descriptor 자동 조회가 없다.
CLI flag 노출이 부족하고, 설정은 JSON 중심이다.
file backend에서는 NVMe write hint, passthrough dspec, 또는 둘 다를 어떻게 쓸지 결정해야 한다.
FDP WAF 또는 latency 효과를 말하려면 유효한 Stage 4 측정이 더 필요하다.

현재 작업​

단계 상태​

실행 기록​

2026-06-12 - Stage 0 계획/문서 소유권 정리​

2026-06-12 - Stage 1 PoC 브랜치 분석 완료​

2026-06-12 - Stage 2 smrc 환경 audit 완료​

2026-06-12 - Stage 3 빌드 + FDP 직접 sanity 완료​

2026-06-12 - Stage 4 harness 준비 및 dry-run 완료​

2026-06-12 - Stage 4 첫 실제 실행 결과: 무효​

2026-06-12 - Stage 4 재시도 준비​

2026-06-15 - Stage 4 재시도 실제 실행 완료, replay 성공 / WAF counter 미완​

2026-06-15 - Stage 4 SMART 재시도 완료, host counter 파싱 성공 / delta 0​

2026-06-15 - Stage 4 stress 실행 완료, replay 성공 / device counter delta 0​

2026-06-15 - Stage 4 stress delta 0 원인 재분석: raw-block slot 크기 오류 확인​

2026-06-15 - Stage 4 slotfix stress 재실행 결과: slot 오류 해결, counter는 여전히 0​

2026-06-15 - Stage 4 status probe 결과: raw-block core는 슬롯을 채웠지만 device counter는 0​

2026-06-15 - raw-device readback으로 실제 write 확인​

2026-06-15 - counter probe 성공: after settle 후 SMART/FDP delta 관측​

2026-06-15 - 3모드 valid 후보 실행 결과: 비교용으로는 보류​

문제 요약​

2026-06-15 - mode window shift 원인 확인​

2026-06-15 - 최종 3모드 동일조건 비교 결과 확보​

2026-06-15 - 반복 실험 준비​

2026-06-15 - vendor media-write counter 확인​

2026-06-15 - WAF probe 1 set​

2026-06-15 - R0 precondition 보강​

plan 시작 이후 변경 파일​

Stage 5 메모​

현재 작업

단계 상태

실행 기록

2026-06-12 - Stage 0 계획/문서 소유권 정리

2026-06-12 - Stage 1 PoC 브랜치 분석 완료

2026-06-12 - Stage 2 smrc 환경 audit 완료

2026-06-12 - Stage 3 빌드 + FDP 직접 sanity 완료

2026-06-12 - Stage 4 harness 준비 및 dry-run 완료

2026-06-12 - Stage 4 첫 실제 실행 결과: 무효

2026-06-12 - Stage 4 재시도 준비

2026-06-15 - Stage 4 재시도 실제 실행 완료, replay 성공 / WAF counter 미완

2026-06-15 - Stage 4 SMART 재시도 완료, host counter 파싱 성공 / delta 0

2026-06-15 - Stage 4 stress 실행 완료, replay 성공 / device counter delta 0

2026-06-15 - Stage 4 stress delta 0 원인 재분석: raw-block slot 크기 오류 확인

2026-06-15 - Stage 4 slotfix stress 재실행 결과: slot 오류 해결, counter는 여전히 0

2026-06-15 - Stage 4 status probe 결과: raw-block core는 슬롯을 채웠지만 device counter는 0

2026-06-15 - raw-device readback으로 실제 write 확인

2026-06-15 - counter probe 성공: after settle 후 SMART/FDP delta 관측

2026-06-15 - 3모드 valid 후보 실행 결과: 비교용으로는 보류

문제 요약

2026-06-15 - mode window shift 원인 확인

2026-06-15 - 최종 3모드 동일조건 비교 결과 확보

2026-06-15 - 반복 실험 준비

2026-06-15 - vendor media-write counter 확인

2026-06-15 - WAF probe 1 set

2026-06-15 - R0 precondition 보강

plan 시작 이후 변경 파일

Stage 5 메모