Un recente problema di logging di Codex ha trasformato un tranquillo database locale in un sorprendentemente intenso generatore di scritture su SSD. Secondo la segnalazione originale su GitHub, i log di feedback SQLite di Codex potevano scrivere circa 640 TB all’anno con il modello di utilizzo riportato. Per un SSD consumer valutato intorno a 600 TBW, quel numero non è solo un piccolo disordine; è vicino alla resistenza in scrittura garantita dell’unità.

La parte strana è che il database dei log non sembrava enorme. Il file poteva restare intorno a un gigabyte, mentre le scritture storiche effettive continuavano ad accumularsi in background. È per questo che questo bug ha attirato così tanta attenzione: non riempiva il disco in modo evidente, ma poteva comunque consumare i cicli di scrittura.

Nota sulla fonte: questo articolo si basa sulla ripubblicazione su BAAI Hub del rapporto di Xinzhiyuan ed è stato verificato con la issue pubblica su GitHub e la discussione su Hacker News. Loghi dei brand, codici QR, inviti a seguire e immagini decorative non correlate presenti nella pagina originale non sono stati inclusi.

Come possono verificarsi 640 TB di scritture su SSD

Il numero sembra esagerato a prima vista, quindi è utile partire dalla misurazione.

Nella issue su GitHub, l’autore della segnalazione ha detto che, dopo circa 21 giorni di uptime, l’SSD principale aveva scritto circa 37 TB. Proiettato su un intero anno, questo diventa circa 640 TB. La principale fonte sospettata era il database locale dei log di feedback SQLite di Codex.

Codex scriveva su file all’interno della directory di configurazione locale:

~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm

Il comportamento non era semplicemente “il file di log continua a crescere all’infinito”. Sembrava piuttosto un ciclo di inserimento e potatura: Codex inseriva nuove righe, poi eliminava quelle vecchie per mantenere stabile il numero di righe conservate. La dimensione visibile del file rimaneva relativamente sotto controllo, ma l’unità doveva comunque gestire le scritture ripetute.

Un campione di 15 secondi tratto dal report mostrava chiaramente il problema:

Ciò significa che circa 36.211 righe sono state inserite in 15 secondi, anche se il numero di righe conservate non è aumentato affatto. Dall’esterno il database sembrava stabile, ma sotto la superficie il churn delle scritture continuava.

Le voci di log frequenti inoltre non erano tutte eventi applicativi di alto valore. Gli esempi includevano rumore ripetuto a livello di filesystem e dipendenze, come gli eventi inotify:

128,764x TRACE log: inotify event: ... name: Some("ld.so.cache")
37,982x TRACE log: inotify event: ... name: Some("locale.alias")
23,843x TRACE log: inotify event: ... name: Some("passwd")

Il risultato era un sistema di logging locale che poteva continuare a riscrivere lo storage offrendo agli utenti pochissimi segnali visibili del fatto che stesse accadendo qualcosa di insolito.

Un file da 1 GB può comunque produrre centinaia di terabyte di scritture

La parte più controintuitiva di questo incidente è semplice: l’usura degli SSD dipende dal totale delle scritture, non dalla dimensione attuale del file.

Un database locale può rimanere intorno a 1 GB mentre l’applicazione scrive, elimina dati, indicizza, esegue checkpoint e riscrive ripetutamente parti di esso. Dal punto di vista dello stato di salute dello storage, ciò che conta non è solo quanto grande appare oggi il file. Ciò che conta è quanti dati sono stati scritti nel tempo.

Il rapporto includeva uno snapshot che rendeva più facile vedere il divario:

Il database attuale conservava solo circa mezzo milione di righe, mentre l’ID di riga autoincrementale aveva già superato i 5,5 miliardi. Questo è il nucleo della questione dell’amplificazione delle scritture: le vecchie righe possono scomparire dalla vista corrente del database, ma le scritture su disco che le hanno create sono già avvenute.

Anche il WAL di SQLite, ovvero Write-Ahead Logging, è rilevante in questo caso. Con la modalità WAL, le modifiche vengono aggiunte a un file -wal separato prima di essere sottoposte a checkpoint e riportate nel database principale. WAL è un meccanismo normale e utile di SQLite, ma quando un’applicazione esegue inserimenti ed eliminazioni molto frequenti, può moltiplicare la quantità di attività su disco che avviene dietro le quinte.

In parole semplici: il notebook sembra ancora sottile, ma le stesse pagine sono state scritte, cancellate e riscritte molte volte.

Causa principale: un’impostazione RUST_LOG che non si è comportata come gli utenti si aspettavano

Il report indicava un dettaglio di configurazione particolarmente importante nel percorso di logging di Codex:

Targets::new().with_default(Level::TRACE)

Nell’ecosistema tracing di Rust, il filtraggio dei log è spesso controllato tramite target e livelli. Gli utenti possono ragionevolmente aspettarsi che la variabile d’ambiente RUST_LOG aiuti a ridurre la verbosità dei log a qualcosa come info, warn o inferiore.

Ma in questo percorso, il sink del log di feedback SQLite utilizzava un valore predefinito di TRACE. TRACE è il livello più verboso e può acquisire dettagli di basso livello delle dipendenze, attività di protocollo grezze e altro rumore di debug. Il report del problema sosteneva che questo valore predefinito significava che il database locale persistente dei log continuava a memorizzare molto più del dovuto.

La distribuzione dei log conservati mostrava quanto fosse dominante il contenuto a livello TRACE:

Il report rilevava inoltre che due sorgenti di log replicate relative a OpenTelemetry, codex_otel.log_only e codex_otel.trace_safe, rappresentavano un’altra grande parte dei byte di log conservati. In quel campione, l’autore della segnalazione stimava che filtrare queste categorie rumorose potesse eliminare la maggior parte del volume di log conservato senza disabilitare completamente i log di feedback.

È per questo che il bug risultava così frustrante per gli sviluppatori. Non si trattava semplicemente di “ti sei dimenticato di configurare il logging”. Sembrava piuttosto: “hai cercato di ridurre il logging, ma questo percorso continuava comunque a salvare log dettagliati”.

Non era il primo problema correlato

Il report non trattava la questione come un singolo incidente isolato. Elencava un gruppo di problemi correlati di Codex riguardanti log SQLite, crescita del WAL, intensa attività del disco e logging locale illimitato o eccessivo.

Alcuni esempi menzionati nel report includevano:

La lezione più importante non è che SQLite sia negativo, o che il logging sia negativo. Entrambi sono utili. La lezione è che un agente locale in esecuzione per sessioni lunghe ha bisogno di un budget di risorse esplicito.

Gli strumenti di coding basati sull’IA sono sempre più trattati come partner di sviluppo sempre attivi. Leggono file, monitorano repository, mantengono vive le sessioni, raccolgono telemetria e preservano il contesto. Questo rende i budget locali di disco, memoria e CPU importanti quanto i budget di token e la qualità del modello.

Le correzioni sono state integrate, ma il dibattito non è finito

La issue di GitHub ha poi aggiunto un aggiornamento in cui si affermava che tre pull request erano state integrate e che il feedback Codex dello stesso segnalatore suggeriva una riduzione stimata dei log dell’85%.

La issue elencava le tre correzioni così:

Una riduzione dell’85% è significativa, ma non equivale a dimostrare che la registrazione locale abbia ora un rigido budget di scrittura a lungo termine. Questa distinzione è il motivo per cui la discussione è proseguita. Gli sviluppatori non chiedevano solo se questo particolare bug fosse stato ridotto; chiedevano se gli agenti di coding basati sull’IA dovessero avere limiti più chiari per la telemetria locale persistente.

La issue su GitHub includeva anche una semplice soluzione temporanea condivisa da un commentatore. Blocca gli inserimenti nella tabella logs creando un trigger SQLite:

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS
  block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE);
  END;"

Usa soluzioni temporanee come questa con cautela. Possono ridurre le scritture dei log locali, ma possono anche eliminare dati diagnostici di cui i team di supporto o gli sviluppatori potrebbero avere bisogno in seguito. In generale, aggiornare a una versione corretta e verificare il comportamento attuale dei log è più sicuro che modificare silenziosamente il database di un’applicazione senza comprenderne il compromesso.

La battaglia degli strumenti di coding sta bruciando più degli SSD

La discussione si è rapidamente spostata oltre il solo Codex. Su Hacker News, gli sviluppatori hanno sollevato anche lamentele più ampie sugli strumenti di coding basati sull’IA: elevato utilizzo della GPU, forte consumo di memoria, attività in background e grandi log di debug locali.

Questa reazione è comprensibile. Gli assistenti di codifica AI moderni non sono più semplici utility da riga di comando. Molti si comportano più come agenti locali: monitorano i progetti, comunicano con modelli remoti, gestiscono il contesto, eseguono comandi e mantengono lo stato tra un’attività e l’altra. Questa potenza è utile, ma crea anche una nuova categoria di responsabilità ingegneristiche.

Uno strumento può sembrare “a posto” nell’interfaccia utente mentre continua a consumare silenziosamente risorse in background. CPU veloci, molta memoria e moderne unità NVMe possono nascondere i problemi per molto tempo. L’app potrebbe non bloccarsi. Il disco potrebbe non riempirsi. Il terminale potrebbe continuare a rispondere. Ma i contatori di salute dell’hardware possono raccontare una storia diversa.

È per questo che questo incidente è diventato un utile caso di studio per gli strumenti di sviluppo AI. Le capacità del modello contano, ma conta anche la qualità operativa locale. Un agente di codifica che risiede sulla macchina di uno sviluppatore ha bisogno di impostazioni predefinite sensate, limiti di conservazione, rotazione dei log e un modo per consentire agli utenti di capire che cosa sta facendo.

FAQ

Che cos’era il bug dei log SQLite di Codex?

Era un problema segnalato di logging di Codex in cui i log di feedback SQLite locali potevano generare quantità molto elevate di scritture su disco. La segnalazione su GitHub stimava circa 640 TB di scritture all’anno in base al modello di utilizzo misurato dal segnalante.

Perché un piccolo file logs_2.sqlite poteva comunque usurare un SSD?

La resistenza di un SSD dipende dalla quantità totale di dati scritti nel tempo, non solo dalla dimensione attuale del file. Un database può inserire, eliminare, scrivere nel WAL, eseguire checkpoint e aggiornare indici ripetutamente pur continuando ad apparire piccolo sul disco.

Che cosa significa SQLite WAL in questo contesto?

WAL sta per Write-Ahead Logging. SQLite scrive prima le modifiche in un file -wal separato e in seguito le trasferisce tramite checkpoint nel database principale, un comportamento normale che però può generare molta attività quando inserimenti ed eliminazioni avvengono molto frequentemente.

Che ruolo ha avuto il logging TRACE?

TRACE è il livello di log più dettagliato. Nel campione segnalato, i contenuti a livello TRACE rappresentavano circa il 70,7% dei byte di log conservati, e la segnalazione sosteneva che log dettagliati di dipendenze e protocolli venissero salvati in modo predefinito.

OpenAI ha risolto il problema di logging di Codex?

L’aggiornamento della issue su GitHub indicava che erano state unite tre PR, con il segnalatore che stimava la possibilità di evitare circa l’85% dei log in base al feedback derivante dal suo utilizzo di Codex. Due correzioni erano indicate come rilasciate in 0.142.0, mentre la terza era indicata come pianificata per 0.143.0.

Gli utenti dovrebbero eliminare o bloccare manualmente i log di Codex?

Le modifiche manuali dovrebbero essere gestite con cautela perché possono rimuovere informazioni diagnostiche e avere effetti collaterali. Un primo passo più sicuro è aggiornare Codex, esaminare i file di log e monitorare i contatori di scrittura dell’SSD se si è preoccupati.

È solo un problema di Codex?

Questa segnalazione specifica era incentrata su Codex. Tuttavia, la preoccupazione più ampia riguarda in generale gli agenti IA locali: gli strumenti sempre attivi hanno bisogno di budget di risorse chiari per disco, CPU, memoria, telemetria e log conservati.

Strumenti correlati

• Repository GitHub di OpenAI Codex: Il repository pubblico per Codex CLI e il relativo codice sorgente.

• SQLite: Il motore di database incorporato utilizzato da molte applicazioni e strumenti locali.

• Documentazione di SQLite sul Write-Ahead Logging: Documentazione ufficiale che spiega come funziona WAL e perché il checkpointing è importante.

• Rust tracing: Il framework Rust per logging strutturato e diagnostica discusso nella segnalazione di Codex.

• smartmontools: Un insieme di strumenti per controllare i dati SMART sullo stato di salute dell’archiviazione, inclusi i contatori di scrittura degli SSD sulle unità supportate.

• Hacker News: La piattaforma di discussione in cui il rapporto sul logging di Codex ha attirato una più ampia attenzione da parte degli sviluppatori.

Link correlati

• Problema #28224 sui log di feedback SQLite di Codex: il principale problema su GitHub che documenta la stima segnalata di 640 TB/anno di scritture e le relative prove.

• Interrompere la registrazione di ogni evento Responses WebSocket #29432: Una delle PR unite elencate come parte del lavoro di riduzione dei log.

• Filtrare i target rumorosi dai log persistenti #29457: La PR incentrata sul filtraggio dei target di logging persistente rumorosi.

• Interrompere la persistenza degli eventi di log instradati tramite bridge #29599: La PR di follow-up mirava a impedire la persistenza degli eventi di log delle dipendenze instradati tramite bridge.

• Discussione su Hacker News: Discussione della community sui log di Codex, le scritture su SSD e la qualità degli strumenti di coding basati sull'IA.

• README di OpenAI Codex CLI: README ufficiale del repository per installare ed eseguire Codex CLI.

• Documentazione WAL di SQLite: Spiegazione ufficiale dei file WAL, dei checkpoint e delle considerazioni sulle prestazioni.