De ontwikkelaars van het project systemd zijn begonnen met het onderzoeken en oplossen van een langdurig architectonisch probleem in de component "systemd-journald", dat leidt tot een meervoudige verhoging van de hoeveelheid gegevens die op de schijf worden geschreven (write amplification) ten opzichte van het feitelijke volume van de logs.
Het verhaal gaat terug tot maart 2020, toen er in het foutopsporingssysteem een rapport werd geregistreerd waarin werd aangetoond dat het genereren van ongeveer 500 KB tekstlogs resulteerde in meer dan 700 MB fysieke schrijfoperaties op de SSD. De ontwikkelaars van systemd weigerden echter ten stelligste het probleem te erkennen en antwoordden in de trant van "jullie begrijpen niet hoe bestandssystemen werken", weigerden profilering uit te voeren en sloten de aanvraag met het oordeel "not actionable". De reacties van de ontwikkelaars verzamelden honderden negatieve beoordelingen van gebruikers, maar de positie van het project bleef onverzettelijk.
Begin 2026 werd er een herhaald rapport over het probleem ingediend, waarin een onafhankelijke ontwikkelaar, ValdikSS, gedetailleerde profilering uitvoerde met behulp van geĆÆsoleerde cgroups en loop-apparaten, waardoor hij het mechanisme van het probleem duidelijk aantoont: door het gebruik van in het geheugen gemapte bestanden (mmap) en binaire hash-tabellen leidt het opslaan van zelfs Ć©Ć©n tekstbericht van 750 bytes tot aanpassing van de vingerafdrukken in het geheugen, wat resulteert in een schrijfoperatie naar de schijf van volledige 4-kilobyte pagina's en de generatie van 50 tot 70 KB uiteindelijke invoer/uitvoer op niveau van het blokapparaat.
Na het artikel over het probleem op de voorpagina van Hacker News gisteren en de publicatie van onbetwiste synthetische tests, hebben de maintainers van het project hun retoriek veranderd en zijn ze begonnen met het optimaliseren van de mechanismen voor het wegschrijven van de cache en de structuur van het opslagindexen van journald.
Bron: opennet.ru
