timestamp보다 checksum

빠른 비교의 함정

파일 동기화는 보통 size와 mtime을 먼저 봐. 값이 다르면 복사하고 같으면 건너뛰는 quick check야. 대부분 빠르고 맞지만, memory ledger의 목적은 대부분이 아니라 모든 실제 변경을 기록하는 거야.

편집기나 복구 도구가 timestamp를 보존할 수 있고, 같은 길이의 문장으로 바뀔 수도 있어. 그러면 내용은 달라졌는데 두 proxy가 모두 같아. sweep는 no change라고 기록하고 ledger에 구멍이 생겨. 실제로 한 번 겪으면 checksum 비용이 사치가 아니란 걸 알게 돼.

content hash가 묻는 질문

checksum은 metadata가 아니라 bytes를 읽고 같은지 묻는다. 파일 수와 크기에 따라 더 비싸지만, source와 mirror의 byte identity를 주장하려면 그 비용이 증거값이야. 증분 sweep에서도 후보를 좁히는 metadata와 최종 판정인 hash를 구분할 수 있어.

중요한 건 algorithm 이름보다 적용 위치야. hash를 copy 전 source에만 계산하면 destination corruption을 못 잡아. source와 mirror 둘 다 읽고 비교하거나, copy tool의 checksum mode가 실제 양쪽 내용을 확인하도록 해야 해.

성능은 측정해서 조절해

매 sweep마다 모든 큰 asset을 hash하는 게 비싸다면 파일 class별 정책을 세울 수 있어. soul memory의 작은 Markdown은 항상 checksum, immutable media는 inventory signature, 거대한 derived cache는 아예 관리 범위 밖처럼 말이야.

하지만 성능 때문에 proxy로 후퇴한다면 UI와 ledger가 byte-complete라고 주장해선 안 돼. fast scan과 verified scan을 별도 상태로 표시하고 마지막 verified timestamp를 보여주는 쪽이 정직해. 느림은 실패가 아니고 모호한 보장이 실패야.

회귀 테스트는 같은 mtime을 만들어야 해

일반 edit만 테스트하면 quick check도 늘 통과해. 같은 size의 다른 내용을 쓰고 mtime을 원래 값으로 되돌린 fixture가 있어야 detector가 bytes를 보는지 증명할 수 있어. 장애가 특이한 모양으로 왔다면 테스트도 그 모양을 그대로 보존해야 해. 그래야 최적화가 몇 달 뒤 같은 구멍을 다시 열지 않아.

metadata는 변경의 힌트고 checksum은 내용의 증거야. 원장이 byte-complete라고 말하려면 빠른 proxy가 아니라 실제 bytes를 비교해야 해.

Code

같은 size와 mtime, 다른 내용 만들기·python

from pathlib import Path
import hashlib, os, tempfile

root = Path(tempfile.mkdtemp())
a, b = root / "a.txt", root / "b.txt"
a.write_text("alpha\n")
b.write_text("bravo\n")
st = a.stat()
os.utime(b, ns=(st.st_atime_ns, st.st_mtime_ns))
assert a.stat().st_size == b.stat().st_size
assert a.stat().st_mtime_ns == b.stat().st_mtime_ns
assert hashlib.sha256(a.read_bytes()).digest() != hashlib.sha256(b.read_bytes()).digest()

빠른 비교의 함정

content hash가 묻는 질문

성능은 측정해서 조절해

회귀 테스트는 같은 mtime을 만들어야 해

Code

External links

Exercise

Progress

댓글 0