S2 Task TODO — raw_block checkpoint overflow
작성: 2026-05-29 관련 문서:
- 종합 분석:
private/work/s2_checkpoint_overflow/s2_verification.md- 현재 재현:
private/work/s2_checkpoint_overflow/repro_checkpoint_overflow.py- Daejun 질문 초안:
private/personal/daejun_question_draft.md- v3 task 등록:
private/tasks/v3_standalone_items.mdS2
진행 원칙
- Daejun(같은 팀)과의 협의가 분기점. 답변 전후로 경로가 갈림.
- 답변 대기 중에도 어차피 필요한 작업은 병렬로 진행.
- **Evidence pack은 "협의 도구"**이지 "공격 자료"가 아님 — 같은 그림 보기 위함.
- 각 단계 산출물을 파일로 남겨 추적 가능하게.
Phase 1 — Evidence Pack 정비 (Daejun 대화 전)
목표: Daejun이 30초~5분에 판단 가능한 형태로 자료 정리. 협의의 효율 ×10.
P1-1. 메커니즘 재현 (60 엔트리) ✅ done
- 스크립트:
private/work/s2_checkpoint_overflow/repro_checkpoint_overflow.py - 결과: payload 10808B > cap 4096B → silent skip → 재시작 시 _index=0
- 코드 경로(
_write_checkpointoverflow 체크)는 production과 동일
P1-2. 선형 스케일링 재현 (4 케이스, 10초 실행) ✅ done
- 스크립트:
private/work/s2_checkpoint_overflow/repro_midscale.py - 출력:
private/work/s2_checkpoint_overflow/repro_outputs/midscale_output.txt - 결과: cap 60KB / 508KB 양쪽에서 동일 패턴 → real default(64MB cap)에도 같은 산수
- 선형 스케일링 증명 → 실측 없이 real-default 임계점 추정 가능
P1-3. real-default 재현 스크립트 (작성만, 실행은 Case B 진입 시) ✅ done
- 스크립트:
private/work/s2_checkpoint_overflow/repro_default_config.py meta_total_bytes=128MB실제 default, 350K 엔트리, RAM 3GB / 디스크 3GB 필요- MODE 환경변수로 memory / file 선택
- 현재 미실행 — Case B 확정 후 1회 돌려 출력 evidence pack에 첨부
P1-4. Before/After #3226 코드 비교 ✅ done
- 파일:
private/work/s2_checkpoint_overflow/s2_before_after_3226.md - 9개 항목 표 + 6개 라인 단위 인용 (PR diff 라인 번호 포함)
- 결론: 천장 동일, silent fail 동일, base 가용 공간 약간 감소
P1-5. 1-페이지 Executive Summary ✅ done
- 파일:
private/work/s2_checkpoint_overflow/s2_one_pager.md - Daejun에게 보낼 단일 자료
- 한 줄 주장 + before/after 표 + 메커니즘/스케일링/Qwen3 임계점 + 질문 1개 + 케이스별 후속
Phase 2 — Daejun 협의 ⏱️ 5~30분 (대기 시간 별도)
⚠️ 2026-06-04 갱신: #3449(zlib 압축) 분석 결과 질문 대상·초점이 바뀜.
- 질문 대상: #3226 → #3449
- 질문 초점: "overflow 다루나요?" → "HC SSD(15/30TB) 영역을 follow-up으로 볼지"
- Std SSD overflow는 #3449로 해소됨 → 단계 1(128MB→512MB) PR 불요
- 갱신된 메시지 초안:
private/personal/daejun_question_draft.md
P2-1. 자료 전달 + 질문
- 채널 결정 (사내 슬랙 > 대면 > 이메일 순)
- 갱신된 질문 초안 확인 후 발송 (
daejun_question_draft.md— HC SSD 영역 focused) - 답변 대기 (며칠 가능)
산출: Case A / B / C 중 분기 결정
Phase 3 — 병렬 준비 (P2 대기 중)
어떤 분기든 어차피 필요한 작업. 답변 와도 바로 PR/이슈 가능하도록.
P3-1. 회귀 테스트 포팅 ⏱️ 1시간
-
tests/v1/storage_backend/test_rust_raw_block_backend.py에 새 테스트 추가_FakeRawBlockDevice+_make_raw_block_core헬퍼 재사용- 작은 cap으로 메커니즘만 확인 (CI 가벼움)
- 추가로
test_raw_block_checkpoint_overflow.py새 파일 검토 - 현재 mainline에서 테스트 실패하는지 확인 (실패해야 의미 있음)
산출: Case A·B·C 모두에 쓸 수 있는 pytest
P3-2. 단계 1 fix 코드 스케치 (Std SSD 커버) ⏱️ 30분~1시간
-
meta_total_bytes기본값 128MB → 512MB (4x)- 위치:
rust_raw_block_backend.py:234 - 정당성: Std SSD 1.92/3.84/7.68TB 전부 커버, 비용 0.025% (7.68TB)
- 위치:
-
meta_versionbump (옛 디바이스 호환)- 위치:
core.py:_DEFAULT_META_VERSION = 1→2
- 위치:
-
_apply_loaded_state에서 옛 디바이스 처리 검토meta_version불일치 시 동작 (현재: ignore + warning. 변경 필요?)
- 변경 라인 수 추정 (~10 라인 예상)
산출: Case B 진입 시 즉시 PR 가능한 패치 초안 (단계 1만)
단계 2 (HC SSD 커버, 2GB bump 또는 binary RFC)는 단계 1 머지 후 별도 트랙. 자세한 단계 분리:
private/work/s2_checkpoint_overflow/s2_verification.md§9
P3-3. 이슈 본문 템플릿 ⏱️ 30분
-
private/work/s2_checkpoint_overflow/s2_issue_template.md - 톤: "[Misc]" 또는 "[Bug]" 결정 보류 (Daejun 답변 후)
- 구조 (유형 A 패턴: #813, #1030 참고):
- Summary (현재 동작 vs scale 시 문제)
- When does it trigger (구체 시나리오 + 임계점)
- Reproduction (P1-1 스크립트 + 출력 첨부)
- Relationship to #3226 (Daejun 답변 인용 자리 — 비워둠)
- Related issues: #1175, #2840 cross-reference
- Suggested directions (단기 + 장기)
산출: Daejun 답변 받자마자 1-페이지 인용만 채워 등록 가능
P3-4. meta_version 호환성 영향 분석 ⏱️ 1시간
- 기존 디바이스에
meta_version=1로 쓰여진 checkpoint를 새 코드(_DEFAULT_META_VERSION=2)로 읽으면 어떻게 되나 - 마이그레이션 옵션 검토:
- (a) 단순 거부: 옛 디바이스는 인덱스 재구축 강제 (= 캐시 한 번 비움)
- (b) 양쪽 read 지원: v1 디바이스도 읽되 새로 쓸 때만 v2
- (c) Daejun #3226의 v1 fallback 패턴 재사용 가능?
- 권장안 결정
산출: 단기 fix PR 본문에 들어갈 호환성 설명
Phase 4 — Daejun 답변별 분기
Case A: "내 PR(#3226) 안에서 처리"
- v3 task 갱신: S2 → "Daejun #3226로 흡수, 우리는 손 떼기"
- P3-1 회귀 테스트를 Daejun에게 PR 제안 (그의 #3226 안에 추가)
- 다음 task로 전환: H1 (즉시), H2 (즉시) 중 선택
- ⏱️ 분기 완료까지 30분
Case B: "직교 영역, 별도로" (가장 가능성 높음)
- 즉시 이슈 등록 (P3-3 템플릿 + Daejun 답변 인용)
- 톤: "[Misc]" 권장 (#813 패턴)
- 단기 fix PR 등록 (P3-2 + P3-4 + P3-1 묶음)
- "Fixes #이슈번호"
- 본문: 재현 출력, 임계점 표, #3226과 직교 관계 설명
- (장기, 시간 여유 시) 바이너리 base 포맷 RFC 이슈 별도 등록
- ⏱️ 이슈 등록 1-2시간 + PR 등록 1일 + 리뷰 사이클 2-3주
Case C: "그 부분 못 봤다, 같이 보자"
- P1-3 자료로 공동 검토
- 공동 이슈 등록 (두 사람 명의) 또는 #3226 follow-up 결정
- 작업 분담 협의
Phase 5 — 사후 (PR 머지 후)
- v3 task 갱신: S2 closed
- contributors.md 갱신: 본인 활동 기록
- verification doc
s2_verification.md에 머지 결과 추가 - (선택) 블로그/내부 공유: "삼성 팀이 자체 HC SSD TCO 분석 도중 발견한 LMCache 버그를 어떻게 발견·수정했나"
마일스톤 요약
| Phase | 산출물 | 시간 |
|---|---|---|
| ✅ P1 (Evidence pack) | one-pager, before/after, 2종 재현 + 출력, 1종 미실행 스크립트 | 완료 |
| P2 (Daejun 협의) | 분기 결정 (Case A/B/C) | 대기 (며칠) |
| P3 (병렬 준비) | 회귀 테스트, fix 스케치, 이슈 템플릿, meta_version 호환 분석 | 3~4시간 (P2 대기 중) |
| P4 (분기) | Case B 시: real-default 1회 실측 + 이슈 등록 + 단기 fix PR | 0.5일~1주 |
| P5 (사후) | 문서 갱신 | 1시간 |
진행 경로 — 단계적 (실장 최소화 + Std/HC 단계 분리)
[지금] Evidence pack ✅ 완료 (실장: 메커니즘 + 선형 스케일링만)
│
▼
[다음] Daejun에게 one-pager 전달 → 질문
│
├──> Case A: 작업 종료, H1/H2로 전환
│
├──> Case B (가장 가능성 높음):
│ 1. real-default 1회 실측 (RAM 또는 디스크 3GB 필요)
│ 2. 출력을 evidence pack에 추가
│ 3. 이슈 등록 (one-pager + 실측 출력 첨부)
│ 4. ⭐ 단계 1 PR: meta_total_bytes 128MB → 512MB (Std SSD 커버)
│ + meta_version bump + 회귀 테스트
│ → 머지 가능성 높음 (modest fix, 메인스트림 사용자 영향)
│ 5. 단계 1 머지 후 → 단계 2 옵션 결정:
│ 2a. 512MB → 2GB bump (HC SSD 30TB까지)
│ 2b. 바이너리 base 포맷 RFC (HC + layerwise까지)
│
└──> Case C: 공동 검토
→ 실장 부담 없이 협의 가능. Case A로 결론나면 실장 자체 불요. → 단계 분리: 단계 1을 보수적으로 통과 → 단계 2 점진적 협상.
다음 행동 (즉시 가능)
현재 wait state: 없음. Phase 1 evidence pack 완료.
선택지 (둘 중 하나로 진행):
- Daejun에게 one-pager 전달 (
private/work/s2_checkpoint_overflow/s2_one_pager.md) — Phase 2 진입 - P3 병렬 준비 먼저 진행 (회귀 테스트, fix 스케치 등) — 답변 대기 시간 활용
권장: 둘 다 동시 시작. Daejun에게 전달은 5분, P3 진행은 답변 대기 중에 무관.
결정 보류 사항 (나중에 정함)
- 이슈 톤: "[Misc]" vs "[Bug]" — Daejun 답변 받은 후 결정 (#813 패턴은 "[Misc]")
- 단계 2 옵션 선택 (2a bump vs 2b binary RFC) — 단계 1 PR 머지 결과 보고 결정
- 호의적 반응 → 옵션 2a (512MB → 2GB) 추가 PR
- 회의적 / raw_block 성숙도 우려 → 옵션 2b 바이너리 base RFC
- 단계 1
meta_total_bytes값은 512MB로 확정 (Std SSD 전부 커버, 0.025% 잠식)