APFS clone extent-level dedup 정밀 회계

[ohing504]

목표

APFS clone으로 실제 디스크를 공유하는 항목의 크기를 extent 수준에서 정확히 회계한다. (#17에서 분리 — 저수준 회계 작업으로 독립)

배경

• code_sign_clone 등은 inode가 달라 stat으로는 공유가 안 보여 apparent size가 overstate된다 (global.go의 codeSignClone 주석 참조).
• extent-level 공유 회계(fcntl F_LOG2PHYS 등)로 실제 점유 디스크를 산출해야 한다.

독립성

• Docker.raw sparse 이미지는 apparent/disk 구분(기존 sparse-aware sizing)으로 이미 정확(apparent 460G / disk 8G)하므로 이 작업과 무관 — Docker(Docker 디스크 이미지 지원 (Docker.raw protected + system prune) #17)의 선행이 아니다.

완료 조건

• extent-level 회계 구현 + 테스트
• 적용 대상(code_sign_clone 등) 크기 정확도 검증

[ohing504]

실측 (2026-07-29)

cp -c 전후 df -k 비교로 clone의 실제 점유를 재는 방법을 확인했다. 별도 도구 없이 검증 가능하다.

cp -c -R "/Applications/Google Chrome.app" ./clone-test.app

du 보고:          722,828 KB
실제 여유공간 감소:      328 KB

약 2,200배 과대보고다. 지금 스캐너가 code_sign_clone 항목에 붙이는 크기는 대부분 이 성격이다.

실물로 굳는 조건

clone이 항상 공짜는 아니다. clone이 남은 뒤 원본 앱 번들이 업데이트로 교체되면 블록 공유가 끊기고, 그때부터 그 clone은 실물이 된다.

같은 날 좀비 10개를 지운 결과가 이걸 뒷받침한다.

• du 합산: 8.2 GB
• 실제 회수: 약 1 GB (여유공간 70Gi → 71Gi)
• 지운 clone의 번들 버전: .129 6개, .184 2개, .187 2개 (설치본은 .187)

구버전 clone만 실물이었고 최신 버전 clone은 공짜였다는 해석과 맞는다.

저비용 근사안

extent 회계(F_LOG2PHYS)를 구현하기 전에, clone 안의 Info.plist CFBundleShortVersionString을 설치본과 비교하는 것만으로 실물 여부를 근사할 수 있다.

• 버전 일치 → 원본과 공유 중, 실제 점유 거의 0
• 버전 불일치 → 공유가 끊긴 실물, 블록 합산이 실제와 가깝다

정확도는 extent 회계에 못 미치지만 stat 두 번이면 되고, 지금의 2,200배 과대보고를 대부분 없앤다.

문서 수정 필요

internal/scanner/global.go의 scanCodeSignClones 주석과 docs/ecosystems.md에 있는 observed: 92 copies / 156 GB는 같은 블록 합산으로 나온 값이라 실제 디스크 사용량이 아니다. 회계가 고쳐질 때 이 수치도 함께 정정한다.

[ohing504]

배수 정정 (재측정)

위 코멘트에서 328 KB 기준으로 약 2,200배라고 썼는데, 같은 측정을 여러 번 돌려보니 실제 점유가 300~800KB 사이에서 흔들린다. 재는 동안 다른 프로세스도 디스크를 쓰기 때문이다.

du 보고:          722,828 KB  (매번 동일)
실제 점유:           328 KB / 600 KB / 776 KB  (실행마다 변동)

배수로 쓰면 900배에서 2,200배 사이다. 단일 측정값을 배수로 못 박지 않는 게 맞다 — 요지는 "세 자릿수 배수만큼 과대보고된다"이고, 그건 어느 실행에서나 성립한다.

재현 스크립트는 cp -c 전후로 df -k를 비교하는 20줄짜리다. 필요하면 테스트로 옮길 수 있다.