Udviklerne af systemd-projektet er begyndt at studere og løse et langvarigt arkitekturproblem i "systemd-journald"-komponenten, der forårsager, at mængden af data, der skrives til disken (skriveforstærkning), er betydeligt højere end den faktiske mængde logfiler.
Historien går tilbage til marts 2020, hvor en rapport blev indgivet i fejlsporingssystemet, der viste, at generering af cirka 500 KB tekstlogfiler resulterede i over 700 MB fysiske skriveoperationer på SSD'er. Systemd-udviklerne benægtede blankt problemet og svarede med et "du forstår ikke, hvordan filsystemer fungerer", nægtede at udføre profilering og lukkede sagen med en dom som "ikke handlingsrettet". Udviklernes kommentarer fik hundredvis af nedstemninger fra brugerne, men projektets holdning forblev urokkelig.
I begyndelsen af 2026 blev en anden problemrapport indsendt, hvor den uafhængige udvikler ValdikSS udførte detaljeret profilering ved hjælp af isolerede cgroup- og loop-enheder, hvilket tydeligt demonstrerede den mekanisme, hvorved problemet opstår: på grund af brugen af hukommelseskortlagte filer (mmaps) og binære hashtabeller resulterer selv skrivning af en enkelt tekstbesked på 750 byte i ændring af hukommelsesfingeraftryk, hvilket får hele 4 kilobyte sider til at blive flyttet til disken og generere 50 til 70 KB resulterende I/O på blokenhedsniveau.
Efter gårsdagens forsiderapport på Hacker News og offentliggørelsen af uigendrivelige syntetiske tests har projektets vedligeholdere ændret deres retorik og begyndt at arbejde på at optimere journalds cache-tømningsmekanismer og indekslagringsstruktur.
Kilde: opennet.ru
