В OpenAI Codex обнаружена ошибка, которая может привести к выходу из строя вашего SSD менее чем за год

Если вы используете — командную строку Codex от OpenAI и оставляете его работать в течение длительного времени, ваш SSD может подвергаться интенсивной нагрузке.

Пользователь GitHub под ником 1996fanrui описал эту проблему 14 июня , заметив необычно высокую активность диска на своём компьютере. Проведя исследование, он обнаружил, что Codex непрерывно перегружает локальную базу данных SQLite (хранящуюся в папке ~/.codex/logs_2.sqlite) записями диагностических журналов. За 21 день работы диск принял около 37 ТБ записей. В годовом исчислении это составляет примерно 640 терабайт. Типичный потребительский SSD объёмом 1 ТБ рассчитан на срок службы около 600 ТБ записи (TBW) — таким образом, эта ошибка, если её не устранить, может исчерпать весь гарантированный ресурс вашего диска менее чем за год.

Причиной является конфигурация ведения журналов, которую, вероятно, никто не собирался предоставлять конечным пользователям. Модуль обработки обратной связи Codex на базе SQLite по умолчанию работает на глобальном уровне TRACE — это максимально «шумная» настройка. Он регистрирует всё: от необработанных данных WebSocket до обычных событий файловой системы, таких как открытие файлов «passwd» и «ld.so.cache». Кроме того, он игнорирует стандартную переменную среды RUST_LOG, поэтому нет очевидного способа уменьшить уровень логгирования. Около 71 % регистрируемых данных представляет собой «шум» уровня TRACE, не имеющий реальной диагностической ценности, по крайней мере для среднего пользователя.

Ситуацию усугубляет амплификация записи. База данных не просто растёт, но и проходит цикл из десятков тысяч операций вставки и удаления в минуту. Физически на диск записывается гораздо больше данных, чем предполагает размер файла.

На самом деле эта проблема в различных формах известна по крайней мере с апреля, и в течение года поступало множество соответствующих сообщений. В недавнем журнале изменений OpenAI упоминались некоторые исправления, касающиеся надёжности SQLite, однако проблема скорости записи осталась нерешённой. Вопрос по-прежнему остаётся открытым.

Тем временем, Linux и macOS могут создать символьную ссылку из «~/.codex/logs_2.sqlite» в «/tmp/», чтобы перенаправить запись в оперативную память. В этом файле не хранятся данные разговоров, поэтому его потеря при перезагрузке не представляет проблемы.