Az OpenAI Codex-ben van egy hiba, amely kevesebb mint egy év alatt tönkreteheti az SSD-t

Ha az OpenAI Codex CLI-jét használod ( ), és hosszú ideig futtatod, az SSD-d túlterhelődhet.

Egy 1996fanrui nevű GitHub-felhasználó június 14-én dokumentálta a problémát miután szokatlanul magas lemezaktivitást észlelt a gépén. Miután utánajárt a dolognak, kiderült, hogy a Codex folyamatosan diagnosztikai naplóbejegyzésekkel terhelte a helyi SQLite adatbázist (amely a ~/.codex/logs_2.sqlite fájlban található). A 21 napos üzemidő alatt a meghajtó körülbelül 37 TB írási műveletet fogadott. Éves szintre vetítve ez nagyjából 640 terabájtot jelent. Egy tipikus 1 TB-os fogyasztói SSD élettartama körülbelül 600 TBW – így ez a hiba, ha nem orvosolják, kevesebb mint egy év alatt kimerítheti a meghajtó teljes garanciális élettartamát.

A hibás egy olyan naplózási konfiguráció, amelyet valószínűleg senki sem akart a végfelhasználóknak szállítani. A Codex SQLite-visszacsatolási rendszere alapértelmezés szerint globális TRACE szinten fut – ez a lehető legzajosabb beállítás. Mindent naplóz, a nyers WebSocket-adatcsomagoktól kezdve a hétköznapi fájlrendszer-eseményekig, mint például a „passwd” és az „ld.so.cache” megnyitása. Emellett figyelmen kívül hagyja a szabványos RUST_LOG környezeti változót is, így nincs nyilvánvaló módja annak lecsökkentésére. A naplózott adatok körülbelül 71%-a TRACE-szintű zaj, amelynek – legalábbis az átlagos felhasználó számára – nincs valódi diagnosztikai célja.

A helyzetet tovább rontja az írási amplifikáció. Az adatbázis nem csupán növekszik, hanem percenként több tízezer beírási és törlési műveletet is végrehajt. Fizikailag sokkal többet ír a meghajtóra, mint amit a fájlméret sugall.

Ez valójában legalább április óta különböző formákban ismert probléma, az év során több kapcsolódó jelentés is érkezett. Az OpenAI legutóbbi változásnaplója említett néhány SQLite-megbízhatósági javítást, de az írási sebesség problémáját nem oldotta meg. A kérdés továbbra is nyitott.

Addig is, a Linux és macOS felhasználók létrehozhatnak egy szimbolikus linket a „~/.codex/logs_2.sqlite” és a „/tmp/” között, hogy az írási műveleteket a RAM-ba irányítsák át. A fájl nem tartalmaz beszélgetési adatokat, így nem baj, ha újraindításkor elveszik.