Systemd projesi geliştiricileri, "systemd-journald" bileşeninde uzun süredir devam eden ve diske yazılan veri miktarının (yazma artışı) gerçek log hacminden önemli ölçüde daha yüksek olmasına neden olan mimari bir sorunu incelemeye ve düzeltmeye başladılar.
Hikaye, Mart 2020'ye dayanıyor; o tarihte hata takip sistemine, yaklaşık 500 KB'lık metin günlüklerinin oluşturulmasının SSD'lerde 700 MB'ın üzerinde fiziksel yazma işlemine yol açtığını gösteren bir rapor gönderilmişti. systemd geliştiricileri sorunu kesin bir dille reddederek, "dosya sistemlerinin nasıl çalıştığını anlamıyorsunuz" şeklinde bir yanıt verdiler, profil oluşturmayı reddettiler ve "işlem yapılamaz" kararıyla bileti kapattılar. Geliştiricilerin yorumları kullanıcılar tarafından yüzlerce olumsuz oy aldı, ancak projenin tutumu değişmedi.
2026 yılının başlarında, bağımsız geliştirici ValdikSS'nin izole edilmiş cgroup ve loop aygıtlarını kullanarak ayrıntılı profil oluşturma işlemi gerçekleştirdiği ikinci bir sorun raporu sunuldu ve sorunun nasıl ortaya çıktığı açıkça gösterildi: bellek eşlemeli dosyaların (mmap'ler) ve ikili karma tabloların kullanımı nedeniyle, tek bir 750 baytlık metin mesajının bile yazılması, bellek parmak izlerinin değiştirilmesine, 4 kilobaytlık sayfaların tamamının diske yazılmasına ve blok aygıt düzeyinde 50 ila 70 KB'lık sonuçlanan G/Ç işlemine neden olmaktadır.
Dün Hacker News'in ön sayfasında yer alan haber ve tartışılmaz sentetik testlerin yayınlanmasının ardından, projenin yöneticileri söylemlerini değiştirerek journald'nin önbellek temizleme mekanizmalarını ve indeks depolama yapısını optimize etmeye başladılar.
Kaynak: opennet.ru
