6년 만에 systemd-journald는 과도한 스토리지 부하 문제를 인정했습니다.

systemd 프로젝트 개발자들은 "systemd-journald" 구성 요소에서 오랫동안 지속되어 온 아키텍처 문제를 조사하고 수정하기 시작했습니다. 이 문제는 디스크에 기록되는 데이터 양(쓰기 증폭)이 실제 로그 용량보다 훨씬 많아지는 현상을 초래합니다.

이 이야기는 2020년 3월로 거슬러 올라갑니다. 당시 버그 추적 시스템에 약 500KB의 텍스트 로그를 생성하는 것이 SSD에서 700MB 이상의 물리적 쓰기 작업을 유발한다는 보고서가 제출되었습니다. systemd 개발자들은 이 문제를 일축하며 "파일 시스템 작동 방식을 이해하지 못하는 것"이라고 답변했고, 프로파일링을 거부하며 "조치할 수 없음"이라는 판결로 티켓을 닫았습니다. 개발자들의 이러한 답변은 사용자들로부터 수백 건의 비추천을 받았지만, 프로젝트 측의 입장은 변함이 없었습니다.

2026년 초, 두 번째 문제 보고서가 제출되었는데, 이 보고서에서 독립 개발자 ValdikSS는 격리된 cgroup 및 루프 장치를 사용하여 상세한 프로파일링을 수행하여 문제가 발생하는 메커니즘을 명확히 보여주었습니다. 메모리 매핑 파일(mmap)과 바이너리 해시 테이블의 사용으로 인해 750바이트 크기의 텍스트 메시지 하나를 쓰는 것만으로도 메모리 지문이 변경되어 4킬로바이트 크기의 페이지 전체가 디스크에 플러시되고 블록 장치 수준에서 50~70KB의 I/O가 발생하는 것입니다.

어제 Hacker News 메인 페이지에 보도된 내용과 반박할 수 없는 합성 테스트 결과가 공개된 후, 프로젝트 관리자들은 입장을 바꿔 journald의 캐시 플러싱 메커니즘과 인덱스 저장 구조 최적화 작업에 착수했습니다.

출처 : opennet.ru