POSIX atime: 파일을 읽기만 해도 쓰기가 발생하는 구조의 문제점

POSIX 표준에 따르면 파일에는 atime(마지막 접근 시간), mtime(마지막 수정 시간), ctime(상태 변경 시간) 세 가지 타임스탬프가 있음. 이 중 atime은 파일을 읽을 때마다 갱신되기 때문에, 모든 읽기가 곧 쓰기가 됨. 디렉토리도 마찬가지임.

왜 문제인가

• 파일을 읽을 때마다 메타데이터 쓰기가 발생하므로 I/O 성능에 악영향을 줌
• CoW(Copy-on-Write) 파일시스템인 Btrfs에서는 특히 치명적임. 읽기만 해도 불필요한 복사가 일어남
• NAND 기반 스토리지에서는 쓰기 횟수가 수명에 직결되므로 YAFFS2 같은 파일시스템은 아예 atime을 저장하지 않음
• 캐시에서 읽어도 atime 갱신 때문에 디스크 쓰기가 발생해 하드디스크가 스핀다운하지 못하는 문제도 있음

Linux의 해결책: relatime

• Linux 2.6.30(2009년)부터 relatime이 기본값으로 도입됨
• atime을 매번 갱신하는 대신, 이전 atime이 mtime/ctime보다 이전인 경우에만 갱신함
• 1일 이상 경과한 경우에도 갱신하여 기존 도구들의 호환성을 유지함

atime을 실제로 사용하는 프로그램들

• tmpreaper / systemd-tmpfiles: 오래 접근하지 않은 임시 파일 삭제에 활용
• Mutt 등 구형 메일 클라이언트: 특정 설정에서 새 메일 확인에 atime 사용
• Debian popularity-contest: 설치된 패키지 중 실제 사용되는 것을 파악하는 데 활용
• 디스크 사용량 분석 도구(agedu, dust): 사용하지 않는 파일 식별에 활용
• relatime은 이 모든 유스케이스를 지원하므로 strict atime은 불필요함

atime의 역사와 잡학

• CVE-2014-5207: atime을 악용해 TOCTOU 공격의 확률적 방어를 무력화하는 기법이 발표됨
• DragonFly BSD: 기본적으로 atime을 비활성화함
• Nix: 가비지 컬렉터에서 atime 지원을 제거함. "실제로 유용하지 않다"는 이유
• 백업 소프트웨어가 atime을 사용한다는 주장이 있으나, 실제로는 HSM(계층적 스토리지 관리) 소프트웨어 하나가 근거이며 대부분의 백업 프로그램은 atime을 무시하거나 우회함
• 1991년 논문에서 이미 atime이 내결함성 기법에 문제를 일으킨다고 지적했으며, 파일 닫기(close) 시점에 갱신하도록 Unix 시맨틱스 변경을 제안함

결론

• 저자는 자신의 ZFS 풀에서 atime을 비활성화함
• 대다수 사용자에게 atime은 이미 쓸모없는 레거시이며, relatime만으로도 필요한 유스케이스를 충분히 커버할 수 있음
• popularity-contest는 inotify로 대체 가능하고, 임시 파일 정리용 atime은 tmpfs에만 활성화하면 됨

원문 링크