오래된 보관본이 수십 기가바이트 있었고 그중 어느 것이 최신인지 가려야 했다. 처음 계획은 mtime을 축으로 삼아 정렬하고 그 순서로 세대를 판정하는 것이었다. 정렬은 잘 됐는데 결과가 어딘가 이상했다.
Table of contents
Open Table of contents
원인 — 시각의 분포가 말해 준 것
각 보관본 안의 mtime을 날짜별로 GROUP BY 해 봤더니 트리마다 모양이 완전히 달랐다. 어떤 트리는 시각이 몇 년에 걸쳐 자연스럽게 흩어져 있었다.
반면 어떤 트리는 모든 파일이 하루 안에 몰려 있었다. cp는 -p나 -a 없이 복사하면 mtime을 복사한 시각으로 새로 찍으니 그 시점에 통째로 옮겨졌다는 뜻이었다. 그런 트리의 mtime은 내용이 언제 만들어졌는지가 아니라 언제 복사됐는지를 가리키고 있었다.
대용 축을 찾아야 했다
mtime이 갱신된 트리는 그 축으로 세대를 가릴 수 없었다. 그래서 안에 들어 있는 CodeIgniter 판 번호를 대신 보기로 했다.
판 번호는 그 시점에 무엇이 쓰였는지를 알려 주므로 시점의 대용이 된다. 다만 이 축은 선후만 가려 주고 두 트리가 얼마나 떨어져 있는지는 알려 주지 않는다. 축을 바꾸면 얻는 것과 잃는 것이 함께 바뀐다는 것을 그때 확인했다.
시각의 세 가지 상태
정리해 보니 mtime이 가질 수 있는 상태가 셋이었다. 원래 값이 보존된 경우와 복사로 갱신된 경우와 아예 없어진 경우다.
뒤의 둘은 축으로 쓸 수 없는데 성격이 서로 달랐다. 없어진 것은 값이 비어 있거나 기본값이라 눈에 바로 띈다. 반면 갱신된 것은 형식도 값도 정상이라 아무 의심 없이 쓰게 된다.
그럴듯한 값이 더 위험하다
깨진 값은 쓰기 전에 걸러지지만 그럴듯한 값은 그대로 결론까지 간다. 이 조사에서 위험했던 것은 없는 mtime이 아니라 갱신된 mtime이었다.
값 하나만 보면 갱신된 것인지 알 수 없고 분포를 봐야 드러난다. 한 파일의 mtime이 이상한지 묻는 대신 이 트리의 mtime 분포가 어떤 모양인지 물어야 했다. 축을 검사하는 단위가 값이 아니라 집합이었다.
축을 쓰기 전에 하는 검사
정렬은 축이 틀려도 결과를 내놓는다. 결과가 나왔다는 사실은 축이 맞는다는 증거가 되지 않는다.
그래서 축으로 쓰기 전에 그 축의 신뢰도를 먼저 검사하는 단계를 넣었다. 분포가 뭉쳐 있는지 보고 뭉친 트리는 다른 축으로 넘긴다. 축을 검사하지 않고 낸 결론은 조용히 틀린 채로 남는다.
정리
- 보관본의
mtime은 트리마다 신뢰도가 다르다 cp가-p없이 복사하면mtime이 복사 시각으로 새로 찍힌다- 갱신된 트리는 안에 든
CodeIgniter판 번호가 시점의 대용이 된다 - 대용 축은 선후만 가려 주고 간격은 알려 주지 않는다
mtime의 상태는 보존과 갱신과 소실 셋이다- 소실은 눈에 띄지만 갱신은 그럴듯해서 그대로 쓰게 된다
- 값 하나가 아니라 분포를 봐야 갱신이 드러난다
- 정렬은 축이 틀려도 결과를 내놓는다