Gli sviluppatori del progetto systemd hanno iniziato a esaminare e risolvere un'antica problematica architettonica nel componente "systemd-journald", che causa un'elevata amplificazione della scrittura su disco rispetto al volume effettivo dei log.
La questione risale a marzo 2020, quando è stata registrata una segnalazione nel sistema di tracciamento dei bug che dimostrava come la generazione di circa 500 KB di log testuali risultasse in oltre 700 MB di operazioni scritture fisiche su SSD. All'epoca, gli sviluppatori di systemd si rifiutarono di riconoscere il problema, rispondendo con un atteggiamento del tipo "non capite come funzionano i filesystem", rifiutando di effettuare un profiling 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 segnalazione ripetuta sul problema, durante la quale il sviluppatore indipendente ValdikSS ha effettuato un dettagliato profiling utilizzando cgroup isolati e dispositivi loop, dimostrando in modo chiaro il meccanismo di origine del problema: a causa dell'uso di file mappati in memoria (mmap) e tabelle hash binarie, la scrittura anche di un singolo messaggio testuale di 750 byte provoca la modifica di blocchi in memoria, dando origine al salvataggio su disco di intere pagine da 4 kilobyte e generando da 50 a 70 KB di I/O finale a livello di dispositivo a blocchi.
Dopo che il rapporto sul problema è apparso nella home page di Hacker News e sono stati pubblicati test sintetici inconfutabili, i manutentori del progetto hanno cambiato retorica e hanno iniziato a lavorare sull'ottimizzazione dei meccanismi di flusso cache e sulla struttura di archiviazione degli indici di journald.
Fonte: opennet.ru
