systemd-journald 이슈: 로그 한 줄이 ext4 49KB, btrfs 110KB 이상 디스크 쓰기라는 주장

btrfs와 COW 파일시스템에서는 작은 쓰기가 특히 비싸더라. 내 유휴 데스크톱 SSD도 2년간 38.7TB가 써졌고, Workrave의 60초마다 stat 동기화나 KDE Klipper의 복사 때마다 저장 같은 문제를 계속 찾아 고치는 중임.

journald의 로그 파일 형식과 UI는 내가 다뤄 본 것 중 최악 축에 듦. 바이너리 로그나 DB 자체가 싫은 게 아니라, 좋은 발상을 형편없이 구현한 경우라고 봄.

Devuan을 초창기부터 써 왔는데 추천함. FreeBSD도 요즘은 꽤 쓸 만함.

journald는 저장소가 아니라 라우터로만 쓰고 디스크 저장은 끄는 편이 낫다고 봄. 인덱스는 느리고 식별자 하나만 골라 로그를 자를 수도 없으며, ag나 rg로 찾는 편이 더 빠를 때가 많음.

과도한 쓰기를 줄이려고 로그를 많이 끄는 작업을 했는데, 예전처럼 프로그램마다 로그 파일이 따로 있으면 어느 파일이 커지는지 찾기가 훨씬 쉬웠음.

차라리 기본 설치에 이미 있는 SQLite3 파일 형식을 썼으면 좋겠음. SQL로 시스템 로그를 조회하면 재미도 있고, 이상한 sd_journal API보다 빠를 가능성도 있음.

systemd가 모듈식이라고들 말하는데 journald가 정말 그렇게 나쁘면 왜 대체 구현이 널리 나오지 않았는지 궁금함.

journald는 압축한 텍스트 로그를 grep하는 것보다도 눈에 띄게 느린 적이 있음. 예전에 저널 파일이 많을 때 퇴화하던 동작을 고쳤지만, 거의 못 쓰는 상태가 그냥 느린 상태가 된 정도였음.

예전에 CoreOS에서 journald를 고칠 때 내 관심사는 journalctl 읽기 성능과 데몬 안정성이었지, 디스크 형식과 쓰기 방식은 못 건드렸음. 형식이 파일 안의 멀리 떨어진 작은 datum을 갱신해서 블록 단위 쓰기 증폭을 부르고, mmap은 커널의 읽기 예측과 페이지 캐시 오염까지 더하는 듯함.

새 로그 줄마다 해시 테이블을 갱신하는 것 같음. 깊게 디버깅한 건 아니지만 코드상 그렇게 보임.

이 작업량은 LSM 트리처럼 append-only로 쌓고 가끔 주 구조에 반영하는 방식이 자연스러워 보임. 쓰기 커서 뒤 페이지도 MADV_DONTNEED로 쉽게 버릴 수 있을 것임.

이 정도 이슈면 수정안도 같이 내야 한다고 봄. 기존 형식보다 낫다는 걸 시험으로 보이는 새 형식을 제안하면 되고, GenAI 덕에 예전보다 그런 작업도 쉬워졌음.

새 디스크 형식은 큰 컴포넌트의 설계 결정이라 새 기여자가 갑자기 PR 하나로 바꿀 일은 아니라고 봄. 먼저 어떤 구성이 좋은지 논의하는 게 맞음.

syslog와 비교하면 이미 답은 어느 정도 나와 있음. syslog는 46년째 있고, 댓글에서 말한 대로 이 경우 더 잘 동작함.