Die systemd-projekontwikkelaars het begin om 'n langdurige argitektoniese probleem in die "systemd-journald"-komponent te bestudeer en op te los wat veroorsaak dat die hoeveelheid data wat na die skyf geskryf word (skryfversterking) aansienlik hoër is as die werklike volume logs.
Die storie dateer terug na Maart 2020, toe 'n verslag in die foutopsporingstelsel ingedien is wat toon dat die generering van ongeveer 500 KB tekslogboeke tot meer as 700 MB fisiese skryfbewerkings op SSD's gelei het. Die systemd-ontwikkelaars het die probleem botweg ontken en gereageer met 'n "jy verstaan nie hoe lêerstelsels werk nie", geweier om profilering uit te voer en die kaartjie met 'n uitspraak van "nie aksievatbaar nie" gesluit. Die ontwikkelaars se kommentaar het honderde afstemme van gebruikers gekry, maar die projek se standpunt het onwrikbaar gebly.
Vroeg in 2026 is 'n tweede probleemverslag ingedien, waartydens die onafhanklike ontwikkelaar ValdikSS gedetailleerde profilering uitgevoer het met behulp van geïsoleerde cgroup- en lustoestelle, wat die meganisme waardeur die probleem voorkom, duidelik demonstreer: as gevolg van die gebruik van geheuegekarteerde lêers (mmaps) en binêre hash-tabelle, lei die skryf van selfs 'n enkele 750-greep teksboodskap tot die wysiging van geheuevingerafdrukke, wat veroorsaak dat volle 4-kilogreep bladsye na die skyf gespoel word en 50 tot 70 KB van gevolglike I/O op die bloktoestelvlak genereer.
Na aanleiding van gister se Hacker News-voorbladberig en die publikasie van onweerlegbare sintetiese toetse, het die projek se onderhouers hul retoriek verander en begin werk aan die optimalisering van journald se kas-spoelmeganismes en indeksbergingsstruktuur.
Bron: opennet.ru
