Projektets udviklere har påbegyndt en undersøgelse og løsning af et langvarigt arkitektonisk problem i komponenten "systemd-journald", som fører til en betydelig stigning i mængden af data, der skrives til disk (write amplification) sammenlignet med det faktiske logvolume.
Historien går tilbage til marts 2020, da en fejlrapport blev registreret i fejlsporingssystemet, hvor det blev demonstreret, at genereringen af omkring 500 KB tekstlogs resulterede i over 700 MB fysiske skriveoperationer på SSD'en. Dengang nægtede systemd-udviklerne blot at anerkende problemet, svarede med "I forstår ikke, hvordan filsystemer fungerer", nægtede at udføre profilering og lukkede anmodningen med dommen "not actionable". Udviklernes kommentarer fik hundreder af negative vurderinger fra brugere, men projektets holdning forblev urokkelig.
I begyndelsen af 2026 blev en ny rapport om problemet sendt ind, under diskussionen gennemførte den uafhængige udvikler ValdikSS en detaljeret profilering ved hjælp af isolerede cgroup og loop-enheder, som tydeligt bevise mekanismen bag problemet: På grund af brugen af memory-mapped filer (mmap) og binære hash-tabeller fører selv skrivning af en enkelt tekstmeddelelse på 750 byte til ændringer i minneaftryk, hvilket forårsager en transfer til disk af hele 4 KB sider og generering af 50 til 70 KB ind- og uddata på blokniveau.
Efter at rapporten om problemet kom frem på Hacker News' forside i går, og offentliggørelsen af ubestridelige syntetiske tests, har projektets vedligeholdere ændret deres retorik og påbegyndt arbejdet med optimering af mekanismerne til cache-udskiftning og strukturen for lagring af journald-indekser.
Kilde: opennet.ru
