Gli sviluppatori del progetto systemd hanno iniziato a studiare e risolvere un antico problema architetturale nel componente «systemd-journald», che porta a un'elevazione multipla del volume dei dati scritti su disco (write amplification) rispetto al reale volume dei log.
La storia risale a marzo 2020, quando un rapporto nel sistema di tracciamento dei bug ha registrato che la generazione di circa 500 KB di log testuali si traduce in oltre 700 MB di operazioni fisiche di scrittura su SSD. A quel tempo, gli sviluppatori di systemd si sono categoricamente rifiutati di riconoscere il problema, rispondendo con un atteggiamento del tipo «non capite come funzionano i file system», rifiutando di effettuare profili e chiudendo la richiesta con il verdetto «not actionable». I commenti degli sviluppatori hanno raccolto centinaia di valutazioni negative da parte degli utenti, ma la posizione del progetto è rimasta ferma.
All'inizio del 2026 è stata inviata una nuova segnalazione sul problema, durante la quale lo sviluppatore indipendente ValdikSS ha effettuato un'analisi dettagliata utilizzando cgroup isolati e dispositivi loop, dimostrando chiaramente il meccanismo di insorgenza del problema: a causa dell'uso di file mappati in memoria (mmap) e tabelle hash binarie, la scrittura di un solo messaggio testuale di 750 byte comporta la modifica dei punteggi in memoria, causando il salvataggio su disco di pagine complete da 4 kilobyte e generando da 50 a 70 KB di ingressi/uscite finali a livello di dispositivo a blocchi.
Dopo che il report sul problema è apparso sulla homepage di Hacker News ieri e la pubblicazione di test sintetici inconfutabili, i manutentori del progetto hanno cambiato tono e iniziato a lavorare sull'ottimizzazione dei meccanismi di svuotamento della cache e della struttura di memorizzazione degli indici journald.
Fonte: opennet.ru
