raw_block NVMe Feature 발굴 (통합, 2026-06-10)
두 발굴 노트 통합본: ① NVMe TRIM 계열(#3519 후속)·MP 빈틈, ② TRIM 외 목표정합 feature. 목표(=
private/goal.txt4 pillar): ① I/O 경로 분석 ② 스토리지 스택 최적화(io_uring·IO scheduler·block alignment) ③ FDP/HC-SSD/Conventional 연결 ④ LMCache backend 기여. 평가기준: 역할별 10%+ 성능, 고객 공동 PoC.
0. 점유 지도 (중복 회피 — 착수 전 필수 확인)
| 영역 | owner / PR | 비고 |
|---|---|---|
| FDP placement 정책 | daegyu94(한대규) | contributors.md "FDP 설계". v3 노트 "중복 금지" |
| FDP directive hook | 이미 존재 (#3274) | _build_nvme_cmd_data(dtype, dspec) 자리 — io_uring_post §3.3/§5.2 |
| io_uring core / NVMe passthrough | ankit-sam #3274 | 머지 임박 (OPEN) |
| checkpoint 포맷/압축 | Daejun #3226(merged)/#3449(open) | |
| non-MP eviction·무결성/LRU | daegyu94 #3394 | |
| sharding/복구 · TRIM(BLKDISCARD) | 상윤 #3519 | #3519 = init 1회 전체 discard |
| SSD wear / write metrics | #2777, #2754 | local_disk 대상 — raw_block 은 빈틈 가능 |
| describe CLI(hit_rate) | #3102 | |
| observability(spans/L0) | #3255, #3607 | L2 storage-stage 지연은 미점유 |
→ FDP "정책+hook"은 daegyu94 레인. 우리 독립 grab 은 placement 정책이 아닌 영역에서 찾아야 함.
#3519(상윤)가 실제로 한 것 — TRIM 기준선
gh pr diff 3519: Rust discard(offset,length) 바인딩(BLKDISCARD=0x1277) + RawBlockCore._discard_full_device()
- config
blkdiscard_on_init(기본 false,load_checkpoint_on_init=False일 때만, 둘 다 true→ValueError). init 시 전체 디바이스 1회 discard,discard_max_bytessplit, 실패는 warning 후 계속. → "시작 시·전체·1회". 런타임 동작은 안 건드림.
1. 축① — NVMe TRIM 계열
⭐ N1 — 런타임 TRIM (슬롯 free 시 discard) — 미착수·미기록, TRIM 계열 1순위
현상태(코드 확인, core.py):
delete_many(:653)·eviction 이 슬롯을_append_free_slot_locked(:1012) 로 인덱스에서만 회수.- 회수 슬롯의 디바이스 바이트 범위에 discard 미발행 — 런타임
discard()호출처 0건(grep). #3519 바인딩은 init 1회 외 미사용. - MP eviction 경로 동일:
raw_block_l2_adapter.py:509→_core.delete_many(force=False).
문제: 장기 가동 캐시(특히 MP, 글로벌 EvictionController 가 churn 주도)에서 evict/delete 바이트가 디바이스에 mapped 잔존 → SSD GC 가 stale 까지 relocate → WAF↑, sustained write latency↑, OP 압박. Samsung NVMe 전략(TRIM 으로 GC 효율 유지) 직결.
제안: #3519 의 discard(offset,length)(per-range) 바인딩 재사용, 슬롯 free 시 범위 discard 발행.
- 배칭: freed range 모아 (a) 연속범위 병합 1회, 또는 (b) 주기적 background sweep(checkpoint thread).
- lock 밖 발행(I/O 는 lock 밖 원칙). config
discard_on_free(기본 false) opt-in. best-effort(OSError→warning, #3519 패턴). - thread-safety: MP Store/Prefetch/Eviction 동시 호출 환경의 freed-range 큐 동시성.
중복: landscape G1~G4·priority 어디에도 없음. #3519 와 "init 1회 vs 런타임 지속" 직교. 단, discard owner = 상윤 → 착수 전 조율 + #3519 머지(Rust 바인딩) 선행.
N2 — 그 외 NVMe data-management (더 큼·탐색적)
| 후보 | 내용 | 판단 |
|---|---|---|
Write Zeroes(BLKZEROOUT) | free 시 zero-fill | discard 보다 무거움, 보안요건 시만. 후순위 |
| DSM access hints | frequency/latency/sequential hints | 효과 측정 어려움, 드라이버 의존. 탐색 |
| FDP placement handle | RU 배치/wear | 메인 리서치·daegyu94 레인. 신규 아님 |
NVMe Copy / BLKCOPY offload | checkpoint/compaction 복사 오프로드 | 큰 설계. 장기 |
2. 축② — MP 모드 raw_block 빈틈
| # | 내용 | 판정 |
|---|---|---|
| MP-A | 런타임 TRIM(=N1) 은 MP 에서 더 중요 — eviction 이 글로벌 EvictionController 로 중앙집중 → churn 집중 → 효과 극대화 | N1 을 MP 관점으로 포지셔닝 가능 |
| MP-B | zero-copy fixed buffer 미등록(=기존 G3) — register_fixed_buffers_from_allocator 는 non-MP plugin 전용, RawBlockL2Adapter 미등록 | #3274 의존(현 브랜치 코드 없음). 신규 아님 |
| MP-C | per_tp_device_paths MP 거부 → 멀티 NVMe TP 샤딩 불가 (mp_vs_non_mp §5·§6) | 큰 설계, 후순위 |
3. TRIM 외 — 목표정합 feature 후보
버킷 A — FDP 가치 실현 (목표 ③④, 전략가치 최상)
| 후보 | 내용 | 판정 |
|---|---|---|
| A1 placement_id plumbing | _write_one→dispatcher→_build_nvme_cmd_data 로 PLID 전달 | hook 존재하나 정책=daegyu94 → 조율 필요, 독립 아님 |
| A2 lifetime stream 분리 | 메타/checkpoint write vs 대용량 KV write 를 다른 placement 로 → WAF↓ | 효과 크나 placement 정책 = daegyu94 |
| ⭐A3 RU-aligned slot geometry | slot/write 단위를 device erase-block / FDP RU 경계에 정렬(config) | 정렬/geometry = 정책 아님 → 우리 독립 영역. arch-review Q4 근거. 목표 ②③ 동시 충족 |
버킷 B — 검증/측정 (목표 ①, 평가기준이 요구)
| 후보 | 내용 | 판정 |
|---|---|---|
| ⭐B1 L2/TTFT 단계별 latency 텔레메트리 | EventBus→OTel, L2 storage-stage 지연 히스토그램 (Task1/B1) | L2 storage-stage 지연 미점유. PoC 수치 백본 |
| B2 raw_block WAF/wear 카운터 | slot churn·discard·write-amp 카운터 | #2777/#2754 와 일부 겹침(local_disk) → raw_block 빈틈 여부 조율 |
버킷 C — HC-SSD & device-aware (목표 ③)
| 후보 | 내용 | 판정 |
|---|---|---|
| C1 HC-SSD checkpoint 2GB 스케일링(S2) | 15/30TB overflow 해소 | 추적 중, Daejun #3449 답변 대기 |
| C2 device-aware store/prefetch(Task5) | 장치 특성 기반 배치 | 백로그, B 측정 선행 |
4. 종합 추천
| 우선 | 항목 | 목표 | 독립성 | 선행조건 |
|---|---|---|---|---|
| ① | B1 L2/TTFT 텔레메트리 | ①(검증) | 높음(L2 stage 미점유) | 기존 EventBus/OTel 재사용 |
| ② | A3 RU-aligned slot geometry | ②③ | 높음(정책 아님) | — (FDP device 시 효과) |
| ③ | N1 런타임 TRIM | ③ | 중(상윤 조율) | #3519 머지 + 조율 |
| — | A1/A2 FDP placement | ③④ | 낮음(daegyu94 레인) | 경계 조율 먼저 |
핵심: placement 정책(A1/A2·N2-FDP)은 daegyu94 레인이므로 단독 착수 금지. 우리가 깨끗이 가져갈 수 있는 건 B1(측정 인프라, 10%·PoC 백본) 과 A3(정렬=정책 아님, ②③ 동시 충족). TRIM 계열에서는 N1(런타임 discard) 이 #3519 후속으로 유효하나 상윤 조율이 전제.
5. 상태 / 다음 액션
상태: 발굴만 완료, task 미등록 (2026-06-10).
- B1: 기존 EventBus/OTel·
latency_histogram_impl_plan.md재사용 범위 확인 → L2 storage-stage 계측점 식별 - A3: 현행
slot_bytes산출 경로(core.py slot 크기 결정) 확인 → RU 정렬 config 삽입점 식별 - N1: 상윤(3xdevv)에게 런타임 discard 를 #3519 후속으로 가져가도 되는지 조율 + #3519 머지 확인
- FDP 방향 시 daegyu94 와 placement(정책) vs geometry(A3) 경계 조율