FDP PoC 검증 + raw_block / file backend 개선 계획서

작성자: Nayeon (Samsung Storage SW) 대상 브랜치: DongDongJu/LMCache:fdp-waf-agentic-replay-poc vs LMCache/LMCache:dev 검증 환경: smrc 서버 (NVMe FDP 지원 확정) 워크로드: tensormesh (LMCache TCO 분석의 워크로드 A) 작업 루트: private/work/fdp/ (산출 노트), ~/workspace/LMCache-fdp-poc (PoC 브랜치 worktree)

Context — 왜 지금 이 task인가

LMCache의 raw_block backend 최적화(L1/L2/L3/P0/V1)가 dev에서 정리되어 가는 가운데 (private/tasks/index.md), 다음 큰 축으로 FDP(Flexible Data Placement) 활용이 잡혀 있다. 한대규(daegyu94)님이 rank-based FDP를 구현했지만 placement_ids[0] 단순 사용에 머무르고, 메타데이터 경로는 미적용·file backend FDP는 미구현 상태다 (2026-W24 일일보고). 동시에 서동주(DongDongJu)님이 NVIDIA PoC용으로 작성한 fdp-waf-agentic-replay-poc 브랜치에는 prompt-aware/phase-aware/per-worker 정책이 더 들어가 있다고 알려져 있다 (fdp_ssd_for_lmcache_raw.md).

이 task의 의도는 두 가지다.

PoC가 smrc 환경에서도 도는지 검증 — NVIDIA 환경에서 작성된 코드가 우리 디바이스/커널에서 빌드·실행되는지, FDP write 경로가 실제 발화되는지를 확인.
검증 결과로 upstream 개선 포인트 도출 — raw_block backend의 placement_id 메타데이터 통로, file backend FDP 경로(write hint vs nvme passthru), daegyu94 라인과의 통합 지점을 PR 단위로 분할.

raw_block design doc의 TODO 라인 42-44 (raw_block.md:42-44) 가 명시한 "FDP / placement-hint support" 빈 자리를 PoC 학습으로 메우는 것이 종착점.

전체 추정: 5.5 ~ 8 일 (블로커 없을 때). 단계 1~3는 직렬, 단계 4·5는 부분 병렬 가능.

역할 분담

단계	주 실행자	실행 위치	Codex의 역할
0. 계획서 보관	Codex	로컬 (`/home/ny/work/fdp`)	plan 파일 정리 + 작업 디렉터리 갱신
1. PoC 브랜치 분석 + 문서화	Codex	로컬 (`/home/ny/work/LMCache-fdp-poc-src`)	fork clone → 코드 읽기 → 문서 작성
2. smrc 환경 audit	Codex	smrc / 현재 세션	`precheck.sh` 실행·보정, raw 출력 파싱, report 작성
3. 빌드 + 테스트	Codex	smrc / 현재 세션	PoC 빌드, raw_block 회귀, FDP sanity smoke
4. 워크로드 측정	Codex	smrc / 현재 세션	PoC harness 실행, 결과 파싱, summary 작성
5. 개선 포인트 도출	Codex	로컬	측정 결과 받은 후 설계 문서 5개 작성

소통 규약:

Codex가 현재 세션에서 접근 가능한 repo·파일·디바이스는 직접 다룬다.
현재 Codex 세션에 smrc NVMe namespace가 노출되지 않은 경우에만 사용자가 raw 출력(텍스트/JSON/로그)을 work/fdp/ 아래 적절한 디렉터리에 붙여넣고, Codex가 이어서 파싱·수정·다음 실행을 진행한다.
디바이스를 지우는 명령(blkdiscard, precondition fill)은 실행 전 target namespace를 명시하고 확인한다.

단계 0 — 계획서 보관 (즉시, Codex)

이 plan 파일은 현재 Codex 작업 디렉터리(/home/ny/work/fdp/PLAN.md)를 source of truth로 둔다.

/home/ny/work/fdp/PLAN.md 보관
README.md에 단계별 산출물 트리 반영
단계 2~4 실행 스크립트 작성
결과가 나오면 SUMMARY.md와 단계별 report를 갱신

단계 1 — PoC 브랜치 분석 + 문서화 (1 ~ 1.5d, Codex)

실행자: Codex (smrc 불필요, 로컬에서 fork clone 후 진행) 목표: DongDongJu fork의 FDP PoC 코드 전체를 분석해서 다음 세 질문에 답하는 문서를 만든다.

코드 구조 전체 지도 — 어떤 파일이 추가/수정되었고, FDP 흐름이 어떻게 연결되어 있는가?
ankit-sam/LMCache#1 포함 여부 — 이 PoC가 ankit-sam의 io_uring_cmd 인프라 PR을 포함하는지 / 일부 변형해 포함하는지 / 별도 인프라인지?
FDP 구현 완성도 — 어디까지 구현됐고 어디가 빈자리인가? (정책 / 메타데이터 / file backend / 테스트 / measurement harness)

산출물 (모두 private/work/fdp/01_branch_audit/ 보관)

branch_diffstat.txt — git diff --stat <merge-base>..PoC 결과
dev_base_commit.txt — PoC가 분기한 dev 시점 commit
01_codebase_map.md — PoC 전체 구조 지도 (디렉터리 트리, 새 파일/수정 파일 분류, 호출 그래프 요약, agentic replay harness 위치)
02_ankit_sam_pr1_diff.md — ankit-sam/LMCache#1 포함 여부 분석
- ankit-sam PR1의 커밋 SHA / patch fingerprint 추출
- PoC 브랜치 git log 에 동일 SHA 또는 동일 patch 내용이 있는지 (cherry-pick / merge / squash 모두 검사)
- 차이가 있으면 어디가 변형됐는지 (변경 hunk 단위)
03_fdp_implementation_audit.md — FDP 구현 범위 audit (다음 카테고리별 Y/N + 위치):
- (a) placement_id 정책 모듈 (prompt-aware / phase-aware / per-worker / static)
- (b) raw_block backend 파라미터 통로 (Python → Rust binding → io_uring_cmd dspec 필드)
- (c) file backend 적용 (fs_l2_adapter.py fcntl(F_SET_FILE_RW_HINT) 흔적)
- (d) NVMe passthrough opcode (NVMe_OP_WRITE w/ DSPEC, identify NS의 NPDA/NPDG)
- (e) 테스트 (단위 / 통합 / 실 디바이스)
- (f) measurement harness (WAF/GC/p99 기록 코드 자체 포함 여부)
- (g) 설정/CLI 노출 (--placement-policy 같은 flag)
placement_policy_notes.md — PoC 안 placement_id 결정 코드 path 자세히 (어느 함수가 prompt_id를 받아 어디서 handle id로 변환하는지)

접근 가정: fork 공개/비공개 미확인 → 우선 ~/workspace에 별도 clone으로 시도. 실패 시 (a) DongDongJu님께 권한/patch 요청, (b) 가능하면 patch 받아 origin dev 위에 적용.

구체 액션

1.1 — Fetch & worktree (앞 단계)

mkdir -p ~/workspace && cd ~/workspace
git clone https://github.com/DongDongJu/LMCache.git LMCache-fdp-poc-src → 실패 시 즉시 escalate
cd LMCache-fdp-poc-src && git checkout fdp-waf-agentic-replay-poc
main repo에 remote 등록: git -C /home/ny/private/LMCache remote add dongdongju https://github.com/DongDongJu/LMCache.git && git -C /home/ny/private/LMCache fetch dongdongju fdp-waf-agentic-replay-poc (push 절대 금지)
ankit-sam fork도 fetch: git -C /home/ny/private/LMCache remote add ankit https://github.com/ankit-sam/LMCache.git && git -C /home/ny/private/LMCache fetch ankit — ankit-sam#1의 head SHA 확보용

1.2 — 코드베이스 지도 작성 (`01_codebase_map.md`)

git merge-base dongdongju/fdp-waf-agentic-replay-poc origin/dev → dev_base_commit.txt
git diff --stat <merge-base>..dongdongju/fdp-waf-agentic-replay-poc > branch_diffstat.txt
git log --oneline <merge-base>..dongdongju/fdp-waf-agentic-replay-poc 전 커밋 메시지 통독
변경 파일을 다음 카테고리로 분류해서 표로 작성:
- raw_block backend (Python core / Rust binding / L2 adapter)
- file backend / fs_l2_adapter
- plugin (placement 정책 모듈 신설 여부)
- agentic replay harness / runner
- tests
- docs / config / 기타
각 카테고리 안에서 호출 그래프를 짧게: "vLLM → LMCache store → RawBlockCore.put → Rust binding → io_uring_cmd" 같은 식으로 PoC 경로 추적
lmcache/v1/storage_backend/raw_block/core.py, rust/raw_block/src/lib.rs, lmcache/v1/distributed/l2_adapters/fs_l2_adapter.py, lmcache/v1/distributed/l2_adapters/raw_block_l2_adapter.py 의 변경 hunk를 직접 읽고 요약

1.3 — ankit-sam/LMCache#1 포함 여부 검증 (`02_ankit_sam_pr1_diff.md`)

ankit-sam PR1의 head SHA와 base SHA 식별: gh pr view 1 --repo ankit-sam/LMCache --json commits,headRefOid,baseRefOid (또는 web UI에서 commits 탭 확인)
PoC 브랜치 git log --oneline ^origin/dev dongdongju/fdp-waf-agentic-replay-poc 의 커밋 SHA / 메시지와 ankit-sam PR1 커밋 비교
patch-id 비교(squash 대응): git log --format='%H' <merge-base>..dongdongju/fdp-waf-agentic-replay-poc | git patch-id --stable ↔ ankit-sam PR1 커밋 patch-id 동일 여부
content diff 비교(rebase 대응): ankit-sam PR1이 건드린 핵심 파일(rust/raw_block/src/lib.rs의 io_uring_cmd 추가 hunk 등)을 PoC에서 grep — 동일 함수 시그니처/같은 enum 정의가 있는지
결론을 다음 4지선다로 명시: (a) 그대로 포함 / (b) cherry-pick으로 포함 / (c) 변형 후 포함 / (d) 미포함, 별도 인프라
(b)/(c)면 변형된 hunk를 표로 정리

1.4 — FDP 구현 범위 audit (`03_fdp_implementation_audit.md`)

다음 7개 카테고리 각각에 대해 표로:

카테고리	구현됐는가 (Y/N/부분)	위치 (파일:라인)	비고
(a) placement_id 정책 모듈			prompt-aware / phase-aware / per-worker / static 중 어느 것?
(b) raw_block backend 통로			core.py put_many 시그니처 변화? Rust FFI 변화?
(c) file backend 적용			`fcntl(F_SET_FILE_RW_HINT)` 흔적?
(d) NVMe passthrough opcode			dspec 필드, identify NS NPDA/NPDG 사용?
(e) 테스트			unit / integration / 실 디바이스
(f) measurement harness			WAF/p99 기록 코드
(g) 설정/CLI 노출			`--placement-policy` 같은 flag?

각 카테고리 별 빈자리(gap) 를 한 줄씩 명시 — 단계 5 설계 입력
단계 5에서 upstream으로 가져갈만한 재사용 가능 컴포넌트 표시

Done 정의

~/workspace/LMCache-fdp-poc-src에 PoC 브랜치 가용 (또는 patch 확보)
01_codebase_map.md / 02_ankit_sam_pr1_diff.md / 03_fdp_implementation_audit.md 3개 문서 작성 완료
다음 세 질문에 한 문장 답변 가능:
1. "FDP 코드가 raw_block backend의 어느 함수 호출에서 placement_id를 주입하는가?"
2. "ankit-sam/LMCache#1이 이 PoC 안에 어떤 형태로 포함되어 있는가?" (포함/변형/미포함)
3. "FDP 구현 7카테고리 중 빈자리는 어디인가?"

단계 2 — smrc 환경 audit (0.5d, Codex 주 실행)

실행자: Codex. 현재 세션에 target NVMe가 보이면 직접 실행하고, 보이지 않으면 사용자가 제공한 raw 출력으로 이어간다. 목표: FDP HW는 확정됐으므로 RUH/RG 파라미터 수집 + toolchain·권한·워크로드 의존성 확인에만 집중.

산출물 (work/fdp/02_smrc_env/)

smrc_env_report.md — Codex가 raw 출력 기반으로 정리
raw/uname.txt, raw/nvme_list.txt, raw/nvme_fdp_configs.txt, raw/nvme_fdp_status.txt, raw/nvme_fdp_stats_baseline.txt, raw/toolchain.txt — 명령 raw 출력
precheck.sh — Codex가 작성·수정·실행
media_write_counter_probe.txt — vendor media-write counter 후보 명령 출력 (PoC harness가 WAF 산출에 필요 — 없으면 1차에서 WAF는 unavailable로만 나옴, run_fdp_waf_stress.py:842-853)

현재 target (2026-06-12):

SN: S77UNG0TC00101
Controller: /dev/nvme0
Block namespace: /dev/nvme0n1
Generic char namespace: /dev/ng0n1
NSID: 1
기본 Endurance Group ID: 1 (필요 시 nvme id-ns 결과로 조정)

Codex 실행 블록:

export NVME_DEV=/dev/nvme0
export NVME_NS=/dev/nvme0n1
export NVME_IO_DEV=/dev/ng0n1
export NVME_NSID=1
export FDP_ENDGRP_ID=1
export OUT=$HOME/ny/fdp/fdp_audit
mkdir -p $OUT/raw

# 1) 커널 + 디바이스 목록
uname -a > $OUT/raw/uname.txt
sudo nvme list > $OUT/raw/nvme_list.txt
sudo nvme id-ctrl $NVME_DEV > $OUT/raw/nvme_idctrl.txt
sudo nvme id-ns $NVME_NS > $OUT/raw/nvme_idns.txt

# 2) FDP 파라미터 (handle 수, RUH, RG)
sudo nvme fdp configs $NVME_DEV --endgrp-id=$FDP_ENDGRP_ID > $OUT/raw/nvme_fdp_configs.txt 2>&1
sudo nvme fdp status $NVME_DEV --namespace-id=$NVME_NSID > $OUT/raw/nvme_fdp_status.txt 2>&1
sudo nvme fdp stats $NVME_DEV --endgrp-id=$FDP_ENDGRP_ID > $OUT/raw/nvme_fdp_stats_baseline.txt 2>&1
sudo nvme fdp usage $NVME_DEV --endgrp-id=$FDP_ENDGRP_ID > $OUT/raw/nvme_fdp_usage.txt 2>&1

# 3) toolchain
{
  echo "=== rustc ==="; rustc --version 2>&1
  echo "=== cargo ==="; cargo --version 2>&1
  echo "=== maturin ==="; maturin --version 2>&1
  echo "=== python ==="; python3 --version 2>&1
  echo "=== liburing ==="; pkg-config --modversion liburing 2>&1 || echo "missing"
  echo "=== nvme-cli ==="; nvme version 2>&1
  echo "=== gcc ==="; gcc --version 2>&1 | head -1
  echo "=== nvidia-smi ==="; nvidia-smi -L 2>&1 | head -5
} > $OUT/raw/toolchain.txt

# 4) 권한 확인 (블록 디바이스 raw 접근 + blkdiscard)
{
  echo "=== block device perms ==="; ls -l $NVME_NS
  echo "=== mount status ==="; mount | grep -i $(basename $NVME_NS) || echo "not mounted"
  echo "=== blkdiscard dry ==="; sudo blkdiscard --help 2>&1 | head -3
} > $OUT/raw/permissions.txt

# 5) 디스크 공간
df -h $HOME > $OUT/raw/df.txt

# 6) Vendor media-write counter 후보 탐색 (PoC harness WAF 산출에 필수)
#    PoC harness는 host_write_bytes (nvme smart-log)와 media_write_bytes (vendor 명령)
#    두 값으로 WAF = media/host 계산. vendor 명령이 없으면 WAF는 unavailable.
#    아래는 후보들 — 디바이스 벤더에 맞는 것이 무엇인지 식별 목적.
{
  echo "=== nvme smart-log standard (host write counter source) ==="
  sudo nvme smart-log $NVME_NS -o json 2>&1 | head -40

  echo "=== nvme smart-log-add (Intel/Solidigm vendor extension) ==="
  sudo nvme smart-log-add $NVME_NS 2>&1 | head -20

  echo "=== nvme wdc vs-smart-add-log (WDC) ==="
  sudo nvme wdc vs-smart-add-log $NVME_NS 2>&1 | head -20

  echo "=== nvme samsung vs-smart-add-log (Samsung) ==="
  sudo nvme samsung vs-smart-add-log $NVME_NS 2>&1 | head -20

  echo "=== nvme ocp smart-add-log (OCP spec) ==="
  sudo nvme ocp smart-add-log $NVME_NS 2>&1 | head -40

  echo "=== nvme get-log (vendor log page 0xC0/0xCA — generic dump) ==="
  sudo nvme get-log $NVME_NS --log-id=0xC0 --log-len=512 2>&1 | head -10
  sudo nvme get-log $NVME_NS --log-id=0xCA --log-len=512 2>&1 | head -10

  echo "=== nvme list-plugins ==="
  sudo nvme list-plugins 2>&1
} > $OUT/raw/media_write_counter_probe.txt 2>&1

# 7) xnvme (PoC harness가 FDP 로그 수집에 사용 — log-fdp-stats / log-ruhu / fdp-ruhs)
{
  echo "=== xnvme version ==="; xnvme --version 2>&1 || echo "missing"
  echo "=== xnvme log-fdp-stats ==="; sudo xnvme log-fdp-stats $NVME_NS --lsi 0x1 2>&1 | head -20
  echo "=== xnvme fdp-ruhs ==="; sudo xnvme fdp-ruhs $NVME_NS --limit 16 2>&1 | head -20
} > $OUT/raw/xnvme_probe.txt 2>&1

echo "Audit complete. Tar and copy: tar czf fdp_audit.tar.gz -C $HOME fdp_audit"

Codex: target SSD /dev/nvme0n1 + /dev/ng0n1로 확정
Codex: precheck.sh를 target 및 --endgrp-id 문법에 맞게 수정
Codex: raw 출력 파싱해서 smrc_env_report.md 작성 — 특히 placement handle 수 N과 io_uring_cmd 사용 가능 여부 명시
Codex: vendor media-write counter 명령 식별

Done 정의

placement handle 수 (N) 확정 — 단계 4 정책 입력
toolchain·권한 OK 또는 부족 항목 리스트업
vendor media-write counter 명령 식별 — media_write_counter_probe.txt에서 가용한 명령을 골라 PoC config의 vendor_media_write_command로 사용. 없으면 1차 WAF는 unavailable (read-only 비교만 가능 — host write delta + RUH 사용량 분포)
smrc_env_report.md 한 페이지 완성

단계 3 — 빌드 + 단위/통합 테스트 (1d, Codex 주 실행)

실행자: Codex. 현재 세션에서 PoC repo와 target device가 보이면 직접 실행한다. 목표: PoC 브랜치를 smrc에서 깨끗하게 빌드, raw_block 회귀 + sanity 통과.

산출물 (private/work/fdp/03_build_test/)

build_log.txt — Rust + Python 빌드 풀 로그
pytest_raw_block.txt — raw_block 관련 회귀 결과
sanity_smoke.md — 작은 chunk write/read 후 nvme fdp stats delta로 FDP 경로 발화 1회 입증

Codex 실행 스크립트:

cd /home/ny/work/fdp/03_build_test
export REPO=/home/ny/work/LMCache-fdp-poc-src
export NVME_DEV=/dev/nvme0
export NVME_NS=/dev/nvme0n1
export NVME_IO_DEV=/dev/ng0n1
export FDP_RUHS=0,1,2,3
export OUT=$HOME/fdp_build_test
bash build_and_test.sh

Codex: PoC의 실제 Rust 모듈 lmcache_rust_raw_block_io.RawBlockDevice 기준으로 sanity script 수정
Codex: build_and_test.sh 작성 (pip install -e ., maturin develop --release, pytest, sanity smoke)
Codex: Rust raw_block extension 빌드 성공 (maturin develop --release)
Codex: sanity_smoke.md에 현재 상태 정리
root 권한 shell에서 FDP direct sanity 실행 (/dev/ng0n1 write/read PASS)
결과 받아서 sanity_smoke.md 최종 PASS로 갱신

Done 정의

raw_block 회귀 PASS (PoC-side known failure는 명시)
FDP write가 NVMe 디바이스에 placement-aware로 도달했음을 nvme stats delta로 1회 입증

단계 4 — tensormesh 워크로드 + FDP 효과 측정 (2 ~ 3d, Codex 주 실행)

실행자: Codex (smrc, 디바이스 점유 + GPU 점유). target namespace를 지우는 R0는 실행 전 재확인. 목표: FDP off vs on 비교, WAF/GC/p99/TTFT/hit ratio 정량화.

측정 순서 (확정 2026-06-11): 1차 PoC 자체 harness 먼저, 2차 tensormesh 나중.

1차 — PoC benchmarks/fdp_waf_stress/run_fdp_waf_stress.py 의 --mode no_fdp/separated/mixed 로 R1/R2/R3 WAF 비교를 통합 작업 없이 즉시 확보 (audit 03_fdp_implementation_audit.md §4). 효과 1차 신호 확인용.
2차 — 1차에서 효과 확인 시 tensormesh 실 워크로드로 확장(TTFT·hit ratio 포함). harness가 자식 LMCache를 subprocess로 띄우는 구조라 tensormesh 통합은 별도 작업(audit §2 (f) gap).
근거: 1차는 통합 비용이 거의 0이라 "효과 유무"를 가장 빨리 가름 → 효과 없으면 tensormesh 통합 전에 방향 재검토.

산출물 (private/work/fdp/04_measure/)

runbook.md — precondition / ramp-up / steady-state 절차, 시드, run당 시간
results_baseline_fdp_off.csv, results_fdp_on.csv
nvme_smart_<run>.json — nvme smart-log JSON
nvme_fdpstats_<run>.txt — nvme fdp stats 시점별 (start/mid/end)
lmcache_metrics_<run>.json — hit ratio, TTFT, p50/p99 read latency
summary.md — 표 + 그래프 + 결론 한 단락

측정 지표 (PoC harness 가용성 매핑은 04_harness_metrics.md §5 참고)

지표	1차 PoC harness	2차 tensormesh	비고
WAF = media_write / host_write	✅ `summary.json::waf` (vendor counter 가용 시)	✅	vendor counter 식별은 단계 2 audit
GC proxy	✅ WAF 자체 + `fdp_logs.ruhu` per-RUH 사용량	✅
p99 read latency	⚠️ `worker_logs/*/records.jsonl` 파싱 필요 (parse_results.py 신설)	✅ LMCache prefetch/load timer
TTFT	❌ 구조적 부재 (storage-level replay)	✅ vLLM harness	2차 전용
Hit ratio	⚠️ harness `disable_metrics=false` + 자식 메트릭 dump 필요	✅ LMCache `/metrics`

1차에서 WAF가 산출되려면 PoC config의 vendor_media_write_command가 smrc 디바이스 벤더에 맞게 채워져야 한다. counter 미식별 시 1차는 host write delta + RUH 사용량 분포만으로 비교. 자세한 내용 04_harness_metrics.md §6.

Run matrix (각 run 별 Codex가 smrc/current session에서 실행)

1차 — PoC 자체 harness (benchmarks/fdp_waf_stress/run_fdp_waf_stress.py, tensormesh 미사용)

ID	내용	시간 (단계 2 후 산출)	실행자
R0	Precondition: `blkdiscard $NVME_NS` → SMART 0 → 용량 C만큼 sequential fill 후 random overwrite로 sustained state 도달	`T_pre = f(C, BW)`	codex
R1	PoC harness `--mode no_fdp` (FDP off baseline, 동일 시드)	`T_run`	codex
R2	PoC harness `--mode separated` (FDP on, prompt 분리)	`T_run`	codex
R3	PoC harness `--mode mixed` (FDP on, 모든 worker 동일 RUH set — class 분리 X, ablation)	`T_run`	codex

R2와 R3 의미 (config.example.yaml 기준): separated는 워크로드 class별로 다른 RUH 할당 (hot_churn→data[0,1]/meta[2], cold_rag→data[3,4]/meta[5] …) — 분리 효과 측정. mixed는 모든 worker가 동일 RUH set — FDP 자체 오버헤드/이득 측정. 단계 1 audit 03_fdp_implementation_audit.md 완료 시 정확한 정의·근거 위치를 이 줄에 갱신.

→ R1 vs R2 WAF delta로 메인 효과 1차 신호. R2 vs R3으로 "효과 원천이 분리인지 FDP 자체인지" ablation. 효과 없으면 여기서 중단하고 단계 5로 (방향 재검토).

2차 — tensormesh 실 워크로드 (1차에서 효과 확인 시에만 진행, harness↔tensormesh 통합 작업 포함)

ID	내용	시간	실행자
R0	Precondition (1차와 동일)	`T_pre`	사용자
R4	tensormesh + FDP off (ramp `T_ramp` + steady `T_steady`)	`T_run`	사용자
R5	tensormesh + FDP on (prompt_id % N, 동일 시드)	`T_run`	사용자
R6	[opt] Phase-aware (prefill vs decode 분리)	`T_run`	사용자
R7	[opt] Per-vLLM-Worker (워커 ≥ 2 시)	`T_run`	사용자

파라미터 현실화 (하드코딩 금지 — 단계 2 audit + 시간 예산으로 확정) 직전 초안의 90% fill / ~30min / ramp30+steady60 / ~90min/run / 3회 평균은 디바이스·워크로드 입력 없이 채운 임의값이었다. 아래 유도식으로 대체하고, 실제 숫자는 단계 2(디바이스 사양)와 시간 예산이 확정된 뒤 채운다.

파라미터 유도 방법 입력 출처
C (용량) nvme id-ns NVM capacity 단계 2 nvme_list / nvme_idctrl
BW (지속 write 대역폭) precondition fill 중 실측 또는 fio seq write 단계 2/3
T_pre (precondition 시간) 용량의 약 1.5~2배 write 필요 → T_pre ≈ (1.5~2)·C / BW. WAF가 sustained(Δ<임계)될 때까지. clean 시작은 WAF 관찰 불가 (refs/fdp_ssd_for_lmcache_ko.md:106-107) C, BW
fill 비율 sustained state 목적이면 ~100% span fill 후 random overwrite (직전 90%는 임의값) C
T_ramp / T_steady tensormesh가 hit ratio·WAF 카운터 안정에 도달하는 실측 시간 — 측정 전 1회 dry run으로 결정 (ramp30+steady60은 임의값) 단계 4 dry run
run 반복 수 smrc 점유 시간 예산 ÷ (T_pre + T_run). 예산 미정이므로 우선 1회(평균 없음), 예산 확보 시 3회 평균으로 확장 시간 예산 (미정)
handle 수 N nvme fdp configs의 RUH 수 → R2 prompt_id % N 단계 2

현재 기본은 1차 R0/R1/R2/R3 각 1회(평균 없음) 최소 셋. 1차에서 효과 확인 시 2차 R4/R5로 확장. 시간 예산이 정해지면 run 반복·steady 길이를 재계산하고, 여유 시 R6/R7·3회 평균으로 확장한다.

파라미터	유도 방법	입력 출처
C (용량)	`nvme id-ns` NVM capacity	단계 2 `nvme_list` / `nvme_idctrl`
BW (지속 write 대역폭)	precondition fill 중 실측 또는 fio seq write	단계 2/3
T_pre (precondition 시간)	용량의 약 1.5~2배 write 필요 → `T_pre ≈ (1.5~2)·C / BW`. WAF가 sustained(Δ<임계)될 때까지. clean 시작은 WAF 관찰 불가 (`refs/fdp_ssd_for_lmcache_ko.md:106-107`)	C, BW
fill 비율	sustained state 목적이면 ~100% span fill 후 random overwrite (직전 `90%`는 임의값)	C
T_ramp / T_steady	tensormesh가 hit ratio·WAF 카운터 안정에 도달하는 실측 시간 — 측정 전 1회 dry run으로 결정 (`ramp30+steady60`은 임의값)	단계 4 dry run
run 반복 수	smrc 점유 시간 예산 ÷ `(T_pre + T_run)`. 예산 미정이므로 우선 1회(평균 없음), 예산 확보 시 3회 평균으로 확장	시간 예산 (미정)
handle 수 N	`nvme fdp configs`의 RUH 수 → R2 `prompt_id % N`	단계 2

Codex 작성/실행 스크립트:

run_R0_precondition.sh — blkdiscard + sequential fill
run_poc_harness.sh — PoC no_fdp / separated / mixed 실행
parse_results.py — run 결과 → CSV 변환 + records.jsonl p99 파싱

측정 캡처 (각 run 공통):

nvme smart-log -o json $NVME_NS 시작/종료 2회 (data_units_written 기록)
nvme fdp stats $NVME_NS 5분 간격 sampling
LMCache 메트릭 (Prometheus / /metrics) 종료 시점 dump
vLLM/tensormesh harness 출력 (TTFT 포함)

구체 흐름

Codex: PoC synthetic trace generator 기반으로 run_poc_harness.sh 작성
Codex: target device /dev/ng0n1 / /dev/nvme0n1 반영
Codex: Stage 4 DRY_RUN=1 검증 완료 (no_fdp, separated, mixed)
Codex/User: R0→R1(no_fdp)→R0→R2(separated)→R0→R3(mixed) 실행 — 첫 actual smoke는 native_storage_ops 누락으로 모든 worker 실패, import/SMART 옵션 수정 후 /home/ny/fdp_measure_retry 재실행 대기
Codex: parse_results.py 결과로 summary.md 표 + 결론 한 단락 작성
1차 효과 확인 시 tensormesh harness 실행 명령/시드/모델 환경을 붙여 R4/R5로 확장

Done 정의

최소 R0/R1/R2 완주
summary 표에 WAF / p99 read / TTFT / hit ratio 4지표 baseline·FDP-on 컬럼
WAF 개선 결론 한 단락 (개선 폭 또는 비개선 가설)

단계 5 — 개선 포인트 도출 (1 ~ 2d, Codex)

실행자: Codex (사용자가 단계 4 결과 공유 후) 목표: 측정 결과 기반으로 raw_block / file backend FDP 통합 설계 초안 + daegyu94 라인 정합 정리.

산출물 (private/work/fdp/05_design/)

raw_block_fdp_integration.md — placement_id 메타데이터를 RawBlockCore → Rust binding → io_uring_cmd 까지 흐르게 하는 인터페이스 변경안 (함수 시그니처, 메타데이터 필드)
file_backend_fdp.md — fs_l2_adapter.py FDP 적용 옵션 비교
- (A) fcntl(F_SET_FILE_RW_HINT, RWH_WRITE_LIFE_*) — 호환성 우선, 커널이 placement handle 매핑
- (B) per-file RW_HINT + 파일 분리 (prompt별 파일)
- (C) io_uring_cmd NVMe passthrough를 file backend에서도 사용 (raw_block과 코드 공유)
poc_patterns_to_adopt.md — PoC에서 upstream으로 가져갈 패턴 (placement 정책 추상화 / 메타데이터 통로 / 테스트 hook)
daegyu94_integration.md — placement_ids[0] 기본인 한대규 라인을 PoC 학습 결과와 합칠 매핑 표
next_prs.md — 후속 PR 분할 (PR-A placement_id 메타데이터 통로 / PR-B prompt-aware 정책 plugin / PR-C file backend write_hint / PR-D nvme_passthru in raw_block)

구체 액션

R1/R2 결과로 "FDP 효과의 주된 원천이 placement 분리 자체인지, phase 분리인지" 결론 → 정책 기본값 결정
RawBlockCore의 put / put_many 시그니처에 placement_hint: Optional[PlacementHint] 추가 안 — 기존 L1/L2/L3/P0/V1 최적화와 충돌 여부 (private/work/raw_block/ 전 노트 참조)
core.py와 rust/raw_block/src/lib.rs 인터페이스 1:1 매핑 — bytes 메타데이터 vs enum/struct
fs_l2_adapter.py의 use_odirect 인근에 write_hint 옵션 신설 위치 식별
daegyu94 라인 review — placement_ids[0]이 모두 동일 handle이면 PoC의 prompt 분리 정책이 어떤 super-set인지 매핑
raw_block.md:42-44 디자인 문서 TODO 업데이트 PR 초안 (이번 task는 plan만, 실제 수정은 후속 PR)

Done 정의

5개 문서 작성 완료
next_prs.md에 ≤4개 PR 단위 작업 큐
daegyu94와 충돌·통합 지점이 표로 정리됨

리스크 & 의존성

리스크	영향	완화 / Fallback
DongDongJu fork private 가능성 (접근 미확인)	단계 1 0순위 블록	`~/workspace`에 clone 시도 → 실패 시 DongDongJu님께 즉시 read 권한 또는 patch 파일 요청. patch 받으면 origin dev 위에 `git apply`로 진행
DongDongJu fork가 dev base와 너무 멀어 빌드 실패	단계 3 블록	(a) `git rebase --onto origin/dev <merge-base>` 시도, (b) 핵심 커밋만 cherry-pick, (c) merge-base 시점 dev로 일시 downgrade하여 baseline 확보
PoC가 #3274 인프라에 의존하나 dev 미머지	빌드/런타임 실패	(a) #3274 PR 브랜치를 mid-base로 끼워 빌드, (b) posix 엔진으로 동작하는 경로만 측정 (FDP 효과 일부 손실 감수)
daegyu94 라인과 인터페이스 충돌	후속 PR 머지 충돌	단계 5 `daegyu94_integration.md`에서 placement 인자 추상화 사전 합의, placeholder enum 유지
워크로드 비결정성으로 R1·R2 노이즈	결론 신뢰도 ↓	동일 시드, precondition 동일화, steady는 dry run으로 결정(`T_steady`), 시간 예산 허용 시 run 3회 평균(미정)
디바이스 rewipe 권한 부재	측정 반복 불가	smrc 관리자에 `blkdiscard` / secure erase 권한 사전 요청 (단계 2 확인)

Verification — task done 증명

재현 명령 (private/work/fdp/REPRODUCE.md):

[Codex, 로컬]

# 1. Branch clone (~/workspace)
mkdir -p ~/workspace && cd ~/workspace
git clone https://github.com/DongDongJu/LMCache.git LMCache-fdp-poc-src
cd LMCache-fdp-poc-src && git checkout fdp-waf-agentic-replay-poc
# → Codex가 단계 1.2 ~ 1.4 문서 3개 작성

[Codex, smrc/current session]

# 2. Env audit (단계 2 명령 블록)
bash $HOME/precheck.sh && tar czf fdp_audit.tar.gz -C $HOME fdp_audit
# → Codex가 raw 출력 파싱

# 3. Build + sanity (단계 3, Codex가 PoC 분석 후 정확한 build 절차로 갱신)
cd /home/ny/work/fdp/03_build_test && bash build_and_test.sh

# 4. Measurement (단계 4, Codex가 작성한 스크립트 사용)
cd /home/ny/work/fdp/04_measure
bash run_R0_precondition.sh
bash run_poc_harness.sh no_fdp
bash run_R0_precondition.sh
bash run_poc_harness.sh separated
bash run_R0_precondition.sh
bash run_poc_harness.sh mixed
python3 parse_results.py "$HOME/fdp_measure" > "$HOME/fdp_measure/results_summary.csv"

보고서

최종 한 페이지 요약: private/work/fdp/SUMMARY.md
- WAF / p99 / TTFT / hit ratio 표
- FDP 효과 결론 (Y/N + 폭)
- 후속 PR 4건 링크 (05_design/next_prs.md)
단계별 디렉터리: 01_branch_audit/ ~ 05_design/
주간 보고에 압축 인용: /home/ny/2026/reports/weekly/2026-W24*.md

Done 최종 정의

PoC 브랜치 smrc 빌드/실행 + sanity test PASS (단계 3)
tensormesh R1·R2 측정 4지표 표 완성 (단계 4)
raw_block + file backend 후속 PR 큐 + daegyu94 통합 매핑 (단계 5)
SUMMARY.md 한 줄 결론 (예: "FDP on에서 WAF X.X→Y.Y, p99 read -Z%, 후속 PR 4건 정의됨")

핵심 참조 파일

lmcache/v1/storage_backend/raw_block/core.py
rust/raw_block/src/lib.rs
lmcache/v1/distributed/l2_adapters/fs_l2_adapter.py
lmcache/v1/distributed/l2_adapters/raw_block_l2_adapter.py
docs/design/v1/distributed/l2_adapters/raw_block.md (TODO 라인 42-44)
private/raw/fdp_ssd_for_lmcache_raw.md — FDP 사용 사례 메모
private/tasks/index.md — 전체 task 인덱스
private/tasks/nvme_raw_block_feature_discovery.md — NVMe feature 발굴 통합본

Context — 왜 지금 이 task인가​

역할 분담​

단계 0 — 계획서 보관 (즉시, Codex)​

단계 1 — PoC 브랜치 분석 + 문서화 (1 ~ 1.5d, Codex)​

1.1 — Fetch & worktree (앞 단계)​

1.2 — 코드베이스 지도 작성 (01_codebase_map.md)​

1.3 — ankit-sam/LMCache#1 포함 여부 검증 (02_ankit_sam_pr1_diff.md)​

1.4 — FDP 구현 범위 audit (03_fdp_implementation_audit.md)​

단계 2 — smrc 환경 audit (0.5d, Codex 주 실행)​

단계 3 — 빌드 + 단위/통합 테스트 (1d, Codex 주 실행)​

단계 4 — tensormesh 워크로드 + FDP 효과 측정 (2 ~ 3d, Codex 주 실행)​

단계 5 — 개선 포인트 도출 (1 ~ 2d, Codex)​

리스크 & 의존성​

Verification — task done 증명​

핵심 참조 파일​

Context — 왜 지금 이 task인가

역할 분담

단계 0 — 계획서 보관 (즉시, Codex)

단계 1 — PoC 브랜치 분석 + 문서화 (1 ~ 1.5d, Codex)

1.1 — Fetch & worktree (앞 단계)

1.2 — 코드베이스 지도 작성 (`01_codebase_map.md`)

1.3 — ankit-sam/LMCache#1 포함 여부 검증 (`02_ankit_sam_pr1_diff.md`)

1.4 — FDP 구현 범위 audit (`03_fdp_implementation_audit.md`)

단계 2 — smrc 환경 audit (0.5d, Codex 주 실행)

단계 3 — 빌드 + 단위/통합 테스트 (1d, Codex 주 실행)

단계 4 — tensormesh 워크로드 + FDP 효과 측정 (2 ~ 3d, Codex 주 실행)

단계 5 — 개선 포인트 도출 (1 ~ 2d, Codex)

리스크 & 의존성

Verification — task done 증명

핵심 참조 파일