본문으로 건너뛰기

Task 제안 v3 — raw_block 개선 아이템

최초 작성: 2026-05-21 / 마지막 갱신: 2026-05-28 성격: 비연결형 — 각 항목이 독립적으로 완결. each item = 1 PR. 모든 항목 코드 레벨 검증 완료 (file:line 근거 포함).

2026-05-26 재검토: raw_block backend 전체 기능/성능 gap 분석 반영. H2(Redis)·M0(폐기)·M1(LFU, 다른 모듈)·M2(local_disk, 다른 백엔드)·S1(allocator wedge, 다른 영역) 제거. #1(자체 eviction)·#7(checkpoint overflow)·#8(FIFO 슬롯) 신규 추가.

2026-05-28 GitHub 교차검증:

  • S1 (자체 eviction) → 🚫 daegyu94 진행 중 (#3394, DongDongJu regression 인정) — 착수 금지
  • S2 (checkpoint overflow) → Daejun #3226과 직교 관계 — #3226은 write 비용 감소가 목적, base overflow는 미해결. 머지 후 별도 fix 가능. Daejun에게 범위 확인 중 (private/personal/daejun_question_draft.md)
  • 신규 컨텍스트: #1175/#2840이 SSD 영속성에 대한 사용자 수요를 명시적으로 보임 → S2의 사용성 근거 강화

난이도 하 (며칠 ~ 1주)​

H1. _free_slots O(n) 멤버십 체크 → O(1)​

  • 위치: lmcache/v1/storage_backend/raw_block/core.py:1019
  • 현상: _free_slots: list[int](:246)에 대해 free 시마다 if slot in self._free_slots 선형 스캔
  • 수정: 병렬 _free_slots_set: set[int]를 추가해 멤버십 체크 O(1). pop/append 시 set 동기화. _apply_loaded_state에서 set 재구성 필요. ~20줄
  • 기대효과: 슬롯 수천 개 이상(대용량 SSD)에서 free 경로 핫스팟 제거
  • 착수 조건: 진행 중인 중복 PR 없음 확인 (2026-05-26 기준 없음)

H2. FIFO 슬롯 재사용 (_free_slots LIFO → FIFO)​

  • 위치: lmcache/v1/storage_backend/raw_block/core.py:1007-1008, 1021
  • 현상: _free_slots.pop() (LIFO) → 막 해제된 슬롯을 즉시 재사용 → 같은 물리 블록에 쓰기 집중
  • 수정: _free_slots를 collections.deque로 교체. append → deque.append, pop() → deque.popleft(). checkpoint 저장 시 list(self._free_slots) 그대로 동작, 로드 시 deque(free_slots)로 초기화. ~10줄
  • 기대효과: 슬롯 전체를 순환 재사용 → wear leveling 개선. FDP placement hint 도입 전 선행 작업으로 적합
  • 착수 조건: H1과 독립적. 동시 작업 가능

난이도 중 (1~2주)​

M1. non-MP write/read 경로에 io_uring 적용​

  • 위치: lmcache/v1/storage_backend/raw_block/core.py:898(_write_one), 549(load_many_into)
  • 현상: io_engine="io_uring" 설정 시에도 두 함수 모두 POSIX(pwrite_from_buffer/pread_into) 사용. io_engine 분기 자체 없음. Rust의 batched_write/batched_read는 MP L2 adapter 전용
  • 수정 (단기): io_engine=="io_uring"일 때 batched_write 1건 submit 후 wait_iouring 대기 → 사실상 동기, io_uring 경로 활성화
  • 수정 (장기): put_many에서 여러 청크를 모아 한 번에 batched_write → 진짜 배치 효과
  • 기대효과: non-MP 경로에서 io_uring이 실제로 동작하도록 함. 현재는 설정만 있고 효과 없음
  • 착수 조건: ankit-sam #3274 머지 후 권장 (builder 전환 + NVMe cmd 경로 안정화 후). zhengfeihe #3271(worker loop) 머지 후 완료 수거 방식 확인

M2. io_uring setup flag 튜닝​

  • 위치: rust/raw_block/src/lib.rs — io_uring 빌더 초기화 지점
  • 현상: SINGLE_ISSUER, DEFER_TASKRUN, COOP_TASKRUN 등 setup flag 전무. #3274가 IoUring::builder() 전환을 하지만 플래그는 추가 안 함 → 플래그 자체는 여전히 빈 자리
  • 수정: #3274 머지 후 builder에 워크로드 맞춤 플래그 추가 + 벤치마크 검증
  • 기대효과: 단일 issuer/worker 구조에 맞는 플래그로 syscall/완료수거 오버헤드 감소
  • 착수 조건: (1) #3274 머지 (builder 전제), (2) #3271 머지 (DEFER_TASKRUN 영향 확인). 플래그별 효과는 커널 버전 의존 → 벤치마크 필수. #3272 벤치마크 툴과 시너지

난이도 상 (2~4주)​

S1. non-MP 경로 자체 eviction → 🚫 daegyu94 진행 중 (2026-05-27 확인)​

  • 상태: 착수 금지 — daegyu94가 #3394에서 동일 이슈 제기, DongDongJu가 regression 인정, daegyu94가 fix 가져감 (2026-05-27)
  • #3394 본문: "After the shared RawBlockCore refactor, non-MP raw-block appears to have lost automatic eviction... was this intentional?"
  • DongDongJu 답변: "It was my fault. It is regression from my previous work changing cache eviction algorithm from backend to global one."
  • daegyu94 의지: "I'll revive it on the in-process mode side."
  • 우리 분석은 유효 — 메커니즘 이해와 FIFO 제안은 daegyu94 PR 리뷰 시 참고 가능
  • 모니터링: daegyu94 후속 PR 등장 시 리뷰 참여

S2. checkpoint 포맷 overflow 수정 (#3226과 직교)​

  • 위치: lmcache/v1/storage_backend/raw_block/core.py:1161-1171(_write_checkpoint), 1213(_checkpoint_once)

  • 현상 (운영 버그): _index 엔트리 수가 payload_cap(기본 ~64MB)을 넘으면 checkpoint가 조용히 실패하고 crash/재시작 후 인덱스 복구 불가. 데이터는 디바이스에 물리적으로 남아 있으나 어느 슬롯에 무엇이 있는지 모르게 됨.

    # _write_checkpoint:1164
    if len(payload) > payload_cap:
        logger.warning("metadata payload too large, skipping checkpoint")
        return False   # ← silent failure (예외 없음, WARNING 한 줄)

  • #3226 (Daejun, incremental checkpoint, APPROVED 2026-05-26)와의 관계 — 정독 완료 2026-05-28:

    • #3226의 목적: full snapshot의 write 비용 감소 (delta 누적 + 주기적 full base)
    • #3226의 비목적: base 자체의 overflow 처리 → S2는 #3226 머지 후에도 살아있음
    • 새 코드의 base는 여전히 json.dumps(snapshot) 전체 직렬화, base_payload_capacity 동일한 ~64MB, overflow 시 동일한 logger.warning + return False (core.py:1164-1171 동일 패턴)
    • 새 layout: delta tail이 같은 mirror 공유 → base 가용 공간이 오히려 약간 줄 수 있음
    • 영향 완화: full 실패해도 이전 base + 살아있는 delta tail로 부분 복구 가능 (delta tail이 차기 전까지). 전량 유실은 줄지만 overflow ceiling은 동일

  • 임계점 (Qwen3-Coder-480B 사례, TP=8 기준 slot 7.75MB):

    • 2.4TB 가득 차면 overflow 시작 → TCO 분석의 Std SSD(3.84/7.68TB), HC SSD(15/30TB) 전부 해당
    • 자세한 표·정정 내역: private/work/s2_checkpoint_overflow/s2_verification.md §3, §6b

  • 검증 완료: fake device(slot 8KB, payload_cap 4KB)에 60 엔트리 → payload 10808B > 4096B → _checkpoint_once False → 재시작 후 _index=0 전량 유실 재현. 재현: private/work/s2_checkpoint_overflow/repro_checkpoint_overflow.py

  • 수정 — Std SSD / HC SSD 단계 분리 (2026-05-29 갱신):

    단계meta_total커버머지 난이도
    1 (Std SSD)128MB → 512MB (4x)1.92~7.68TB Std 전부낮음
    2a (HC bump)512MB → 2GB (16x 총)+ 15~30TB HC중간
    2b (binary RFC)동일+ layerwise높음 (3-6개월)
    • 단계 1: 즉시 PR. meta_version bump 포함. 비용 0.025% (7.68TB), 사실상 무료. 이미 영향받는 메인스트림 사용자 → 정당성 강함.
    • 단계 2: 단계 1 머지 후 결정. 메인테이너 반응 호의적이면 2a, 회의적이면 2b RFC.
    • 자세한 단계별 커버리지·정당성: private/work/s2_checkpoint_overflow/s2_verification.md §9

  • 2026-06-04 재평가 — #3449(zlib 압축) 반영:

    • #3449 실측 압축률 4.6x → Std SSD(3.84/7.68TB) overflow 해소됨
    • HC SSD(15/30TB)에서는 여전히 overflow 잔존 (압축 후 ~90/~180MB > cap 64MB)
    • 단계 1(128MB→512MB) PR 불요 — HC SSD 직접 겨냥하는 단계 2a(2GB bump)로 재설정
    • 자세히: private/work/s2_checkpoint_overflow/s2_verification.md §10

  • 착수 조건 (갱신):

    1. 선행: Daejun에게 #3449 관련 HC SSD 영역 확인 (private/personal/daejun_question_draft.md)
    2. #3449 머지 후 HC SSD 영역만 남은 단계 2a 작업
    3. 회귀 테스트: private/work/s2_checkpoint_overflow/repro_checkpoint_overflow.py + repro_s2_midscale.py를 test_rust_raw_block_backend.py의 _FakeRawBlockDevice/_make_raw_block_core로 포팅

우선순위 요약​

항목난이도긴급도권장 순서
S2 (checkpoint overflow)상🟡 HC SSD(15/30TB)만 잔존Daejun(#3449) 답변 후 단계 2a 착수 — Std SSD는 #3449로 해소 (2026-06-04 재평가)
H1 (_free_slots O(1))하🟡즉시 착수 가능 (다른 PR과 충돌 없음)
H2 (FIFO 슬롯)하🟡즉시 착수 가능, FDP 전 선행
S1 (자체 eviction)——🚫 daegyu94 진행 중 (#3394) — 착수 금지
M1 (non-MP io_uring)중🟡#3274 머지 임박 (6/1 DongDongJu APPROVED, 6/3 ApostaC doc 코멘트만 남음) → 착수 가능 윈도우 열림
M2 (setup flag)중🟡#3274 머지 후 착수 — 위 동일 타이밍, #3271도 확인 필요

공통 원칙: 착수 전 같은 항목을 다루는 오픈 PR 최신 diff 확인. 중복 금지 영역 (2026-06-04 갱신):

  • FDP placement 정책: daegyu94 진행 중
  • non-MP 자체 eviction (S1): daegyu94 진행 중 (#3394)
  • raw_block checkpoint 압축·overhead: Daejun 진행 중 (#3226 merged, #3449 OPEN) — S2는 #3449 머지 후 HC SSD 영역만 남음, Daejun 답변 후 착수