본문으로 건너뛰기

S2 — raw_block checkpoint silent overflow (1-pager)

작성: 2026-05-29 / 최종 갱신: 2026-06-04 / 대상: 박대준 책임 (#3226, #3449 author) 목적: #3449(zlib 압축) 반영 재평가 → HC SSD(15/30TB) 영역 확인 질문으로 전환 상태: #3449 분석 후 Std SSD overflow 해소 확인 — HC SSD만 살아있음

한 줄 주장​

_write_full_base(이전 _write_checkpoint)에서 base JSON이 base_payload_capacity(기본 ~64MB)를 넘으면 logger.warning + return False로 silent skip → 재시작 시 인덱스 유실. #3226 머지 후에도 동일 코드 경로로 살아있음. (core.py:1164-1171 → diff:716-720, 동일 패턴 그대로)

코드 (Before/After #3226)​

항목BeforeAfter (#3226)변화
base 직렬화json.dumps(snapshot)(동일)❌
overflow 체크if len(payload) > payload_cap(동일)❌
overflow 시warning + return False(동일, silent)❌
capacity 식container_bytes - block_alignbase_copy_bytes - block_align (≈동일 값)이름만
mirror 공간base 전용base + delta tail (공유)base 가용 ↓

전체 비교: private/work/s2_checkpoint_overflow/s2_before_after_3226.md

재현 (실측)​

메커니즘 — 60 엔트리, payload_cap 4KB (가벼움)​

저장 성공: 60/60 entries (데이터는 정상 기록)
checkpoint payload: 10808B > cap 4096B → overflow
_checkpoint_once(force=True) = False  ← silent skip
meta_seq = 0  ← 한 번도 안 써짐
--- 재시작 ---
복구된 _index = 0  ← 전량 유실

스크립트: private/work/s2_checkpoint_overflow/repro_checkpoint_overflow.py

선형 스케일링 — 중간 cap에서도 동일 (10초 실행)​

케이스 1: cap=60KB, 200 엔트리 (cap의 0.57배) → OK, 200 복구
케이스 2: cap=60KB, 400 엔트리 (cap의 1.13배) → OVERFLOW, 전량 유실
케이스 3: cap=508KB, 2000 엔트리 (cap의 0.67배) → OK, 2000 복구
케이스 4: cap=508KB, 3500 엔트리 (cap의 1.17배) → OVERFLOW, 전량 유실

스크립트: private/work/s2_checkpoint_overflow/repro_midscale.py, 출력: private/work/s2_checkpoint_overflow/repro_outputs/midscale_output.txt

→ payload_cap 절대값과 무관, 엔트리 수와 cap의 비율만이 trigger. 실제 default(cap≈64MB)에서 임계 ≈ 321,000 엔트리 (~82M distinct 토큰).

실제 default 재현용 스크립트 (작성 완료, 실행 대기)​

private/work/s2_checkpoint_overflow/repro_default_config.py — meta_total_bytes=128MB (실제 default) 그대로, 350K 엔트리로 production 천장 직접 초과. RAM 3GB 또는 디스크 3GB 필요. (실행은 Case B 확정 시 1회 실시 후 출력 evidence pack에 첨부)

임계점 — Qwen3-Coder-480B 사례 (TCO 분석 모델)​

디바이스TCO 분류TP=8 가득 시 엔트리JSONoverflow
1.92TB소형260K52MBno (간당)
3.84TBStd SSD520K104MBYES
7.68TBStd SSD1.04M207MBYES
15TBHC SSD2.08M414MBYES
30TBHC SSD4.16M828MBYES

(Qwen3-480B, TP=8 → slot 7.75MB. 자세히: private/work/s2_checkpoint_overflow/s2_verification.md §6b)

→ TCO 분석 모든 디바이스 옵션이 가득 차면 overflow. HC SSD 전용이 아니라 표준 7.68TB도 해당. → Coder + 256K 컨텍스트 → distinct 작업셋 큼 → steady state에서 가득 참 → 자기선택적 trigger.

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

#3449 압축 효과 (실측 4.6x) 적용 시 임계점 갱신:

디바이스원본 JSON압축 후overflow?상태
3.84TB Std104MB~23MB✅ 해소#3449로 충분
7.68TB Std207MB~45MB✅ 해소 (여유 19MB)#3449로 충분
15TB HC414MB~90MB❌ 여전히 overflowS2 살아있음
30TB HC828MB~180MB❌ 여전히 overflowS2 살아있음

→ Std SSD overflow 해소, HC SSD(15/30TB)만 잔존.

영향 완화는 있음 (전량 유실 → 부분 복구)​

#3226/#3449 적용 시 base가 한 번이라도 성공적으로 써졌다면, 이후 cap 초과로 full 실패해도 delta tail이 살아있으면 부분 복구 가능. 단:

  • 첫 base 시점 이후 변경분만 복구
  • delta tail이 가득 차면 동일 silent fail
  • 천장 자체는 그대로

질문 (갱신됨)​

#3449 압축 덕에 Std SSD(7.68TB까지) overflow는 해소된 것으로 분석했습니다. HC SSD(15/30TB)에서는 압축 후에도 여전히 payload가 cap을 초과합니다 — 이 영역을 별도 follow-up으로 볼지, #3449 범위 확장으로 다루실지 확인하고 싶습니다.

답변 케이스별 우리 후속 (참고)​

Case우리 행동
A. #3226 범위 내 처리우리 손 떼기. 재현 스크립트를 회귀 테스트로 #3226에 제안
B. 직교 영역, 별도로(가장 가능성 높음) 단계 분리 전략: ① Std SSD 커버 PR (128MB→512MB, 즉시) ② HC SSD 커버는 단계 1 머지 후 (2GB bump 또는 binary RFC)
C. 같이 보자공동 검토, 작업 분담

Case B 단계 분리 — 왜?​

단계meta_total커버머지 난이도
1 (Std SSD)128MB → 512MBStd SSD 전부 (1.92~7.68TB)낮음 — 이미 영향받는 메인스트림 사용자
2a (HC bump)512MB → 2GB+ HC SSD 30TB까지중간 — Samsung 데이터 보강 권장
2b (binary RFC)동일+ layerwise까지높음 — RFC 토론 3-6개월

→ "단계 1을 보수적 modest fix로 빠르게 통과 → 단계 2는 그 위에서 점진 협상." 비용은 사실상 무료 (30TB에서 0.007% 잠식). 자세히: s2_verification.md §9.

첨부 자료 위치​

  • 종합 분석: private/work/s2_checkpoint_overflow/s2_verification.md (9 섹션, 12 페이지)
  • before/after 코드 비교: private/work/s2_checkpoint_overflow/s2_before_after_3226.md
  • 재현 스크립트: private/work/s2_checkpoint_overflow/repro_*.py (3종)
  • 재현 출력: private/work/s2_checkpoint_overflow/repro_outputs/