Task 제안 v1 — 원래 구상한 5-task 로드맵

작성: 2026-05-21 / 성격: 단기→중기→장기 연결형 (관측·정책 레이어 중심) 상태: 보류 (FDP 항목은 한대규가 진행 중이라 제외 검토됨)

L2 스토리지 tier의 관측성과 정책 primitive를 강화하는 5개 업스트림 기여 task. 모두 Samsung NVMe FDP/HC-SSD 포지셔닝에 도움이 되면서 upstream 수용 가능한 범위로 선정.

#	Task	추정	의존성
1	L2 staged latency histogram subscriber	3주	—
2	`lmcache storage describe` CLI 명령	2.5주	—
3	`fs_connector` O_DIRECT 메타데이터 경로 지원	2.5주	—
4	L2 adapter 레이턴시/용량 health check	5주	Task 1
5	Device-aware prefetch/store policy	7주	Task 1

연결 구도

Task 1 (레이턴시 텔레메트리 생산)
   ├──> Task 4 (health check — 레이턴시 소비)
   └──> Task 5 (device-aware policy — 레이턴시 소비)

Task 2, 3 (독립, Task 1과 병렬 가능)

Task 1이 단계별 타이밍 데이터를 만들고 → Task 4·5가 그걸 소비. Task 4·5는 Task 1 없이는 설계 불가.

목표: L2 store/load 경로의 단계별 레이턴시 히스토그램 추가 → Task 4·5에 데이터 공급.

실현가능성 (2026-05-18 검증):

EventBus + subscriber 인프라 완비 (lmcache/v1/mp_observability/)
L2_STORE_SUBMITTED/COMPLETED, L2_LOAD_TASK_SUBMITTED/COMPLETED 이벤트 타입 이미 정의 (event.py)
l2_throughput.py 가 거의 복붙 가능한 템플릿 (pending dict + correlation key + OTel histogram)
테스트 패턴: tests/v1/mp_observability/subscribers/metrics/test_l2_throughput.py

설계 결정 — stage model: 원래 4단계 균일안(queue_wait/adapter_internal/disk_io/completion)은 어댑터마다 안 맞음:

채택 모델 (adapter-aware 2+N):

공통 (전 어댑터): *_DISPATCHED 이벤트 1개 추가로 2단계
- SUBMITTED → DISPATCHED = queue_wait_ms
- DISPATCHED → COMPLETED = processing_ms
raw_block 전용: *_IO_SUBMITTED/COMPLETED 추가 → 실제 disk-I/O 레이턴시

PR 분할:

PR	범위	규모	추정
#1	`*_DISPATCHED` 이벤트 + 각 어댑터 worker 진입점 1줄 publish + `l2_latency.py` subscriber + 테스트	~400줄	1~1.5주
#2	`raw_block` 전용 `*_IO_SUBMITTED/COMPLETED` (subscriber는 optional 처리)	~200줄	1주
#3	(선택) `docs/design/v1/mp_observability/` 이벤트 계약 + 버킷 튜닝	~150줄	0.5주

PR #1 전 확인할 리스크:

Task 2 lmcache storage describe: 어댑터 타입/디바이스 경로/용량/레이턴시 분포를 CLI로 노출. (참고: #3102 maobaolong이 hit_rate 추가 중, #3320 sammshen이 용량/사용량 메트릭 추가 중 — 둘 다 보완 관계, 레이턴시·디바이스 메타데이터는 빈 자리)
Task 3 fs_connector O_DIRECT 메타데이터: 현재 데이터 I/O만 O_DIRECT, 메타데이터 경로는 일반 path. Samsung SSD 성능 검증과 직결. (참고: #3191 zhengfeihe는 non_cuda_equivalents 핀 포인터 정렬 → fs_connector 메타데이터 경로와 무관, 중복 아님)
Task 4 L2 health check: Task 1 레이턴시 데이터 소비 → p99 임계값 초과 감지/alert.
Task 5 device-aware policy: 레이턴시 기반으로 어느 어댑터에 prefetch/store할지 결정. (참고: 로드맵에 "Advanced L2 store/prefetch policies", "Dynamic prefetch admission controller" 명시 — upstream도 원하나 아직 오픈 PR 없음. 단 #3269 abinggo가 admission 관련 작업 중 → 착수 전 재확인)

#3320(sammshen): L2 용량/사용량 메트릭 — 레이턴시 아님 → Task 1과 구분
#3272(zhengfeihe): raw_block 오프라인 프로파일링/latency 분포 — Task 1은 라이브 mp_observability OTel 히스토그램 → 레이어 다름, 구분됨
결론: Task 1(라이브 단계별 L2 레이턴시)은 여전히 빈 자리