Programiści projektu systemd rozpoczęli badanie i usuwanie od dawna istniejącego problemu architektonicznego w składniku „systemd-journald”, który prowadzi do wielokrotnego zwiększenia objętości danych zapisywanych na dysku (write amplification) w porównaniu do rzeczywistej objętości logów.
Historia sięga marca 2020 roku, kiedy w systemie śledzenia błędów został zarejestrowany raport, w którym udowodniono, że generowanie około 500 KB tekstowych logów wiąże się z ponad 700 MB fizycznych operacji zapisu na SSD. Programiści systemd wówczas zdecydowanie odmówili uznania problemu, odpowiedzieli w stylu „nie rozumiecie, jak działają systemy plików”, odmówili przeprowadzenia profilowania i zamknęli zgłoszenie z werdyktem „not actionable”. Komentarze programistów zebrały setki negatywnych ocen od użytkowników, jednak stanowisko projektu pozostało nieugięte.
Na początku 2026 roku wysłano ponowny raport o problemie, w trakcie dyskusji niezależny programista ValdikSS przeprowadził szczegółowe profilowanie z użyciem izolowanych cgroup i urządzeń loop, dobitnie udowadniając mechanizm powstawania problemu: z powodu użycia mapowanych w pamięci plików (mmap) i binarnych tabel haszujących zapis nawet jednego tekstowego komunikatu o wielkości 750 bajtów prowadzi do modyfikacji odcisków w pamięci, co powoduje zrzut na dysk pełnych 4-kilobajtowych stron i generację od 50 do 70 KB końcowego I/O na poziomie urządzenia blokowego.
Po wczorajszym umieszczeniu raportu o problemie na głównej stronie Hacker News oraz opublikowaniu niepodważalnych syntetycznych testów, widzowie projektu zmienili retorykę i rozpoczęli prace nad optymalizacją mechanizmów zrzutu pamięci podręcznej oraz struktury przechowywania indeksów journald.
Źródło: opennet.ru
