جدول المحتوى

.

L’interface en ligne de commande (CLI) d’OpenAI Codex présente un bug critique lié à une écriture excessive de données, menaçant directement la durée de vie physique des SSD. Selon des rapports techniques, une erreur de configuration du système de journalisation pourrait entraîner l’écriture de jusqu’à 640 To de données par an sur le disque, dépassant largement la capacité de charge de la plupart des SSD grand public actuels.

Une découverte choquante au sein de la communauté technologique.

Le problème a été porté à l’attention pour la première fois lorsqu’un utilisateur de GitHub nommé 1996fanrui a remarqué une activité disque anormalement élevée sur son système à la mi-juin. Après avoir mené une analyse approfondie, il a découvert qu’OpenAI Codex écrivait continuellement des données dans une base de données SQLite locale à l’emplacement ~/.codex/logs_2.sqlite .

Des données réelles montrent qu’après 21 jours de fonctionnement continu, le disque dur a accumulé environ 37 To de données écrites. Sur une année, cela représente environ 640 téraoctets (To). À titre de comparaison, un SSD classique de 1 To a généralement une endurance d’environ 600 To. Par conséquent, ce seul bug logiciel pourrait potentiellement anéantir la durée de vie d’un SSD neuf en moins de 12 mois.

Cause technique : Lorsque les niveaux de journalisation deviennent incontrôlables.

Le problème fondamental réside dans la configuration de journalisation qu’OpenAI semble avoir négligée par inadvertance lors de sa mise à disposition aux utilisateurs finaux. Le système de réponse SQLite du Codex fonctionne par défaut au niveau TRACE global. Or, ce niveau est le plus bruyant en programmation, car même les événements les plus infimes y sont enregistrés.

Le système enregistre tout, des paquets WebSocket bruts aux événements courants du système de fichiers, comme l’ouverture des fichiers de configuration système (passwd ou ld.so.cache). Il est à noter que le logiciel semble ignorer la variable d’environnement standard RUST_LOG , privant ainsi les utilisateurs de tout moyen simple de réduire le niveau de journalisation par les méthodes classiques.

Une analyse plus poussée a révélé qu’environ 71 % des données enregistrées étaient constituées de bruit de niveau TRACE, dépourvues de toute valeur diagnostique pratique pour l’utilisateur moyen.

Effet d’amplification d’écriture

Le problème ne se limitait pas à l’augmentation de la taille du fichier journal. La nature même de la base de données SQLite, dans ce cas précis, entraînait une forte amplification des écritures. Au lieu de simplement écrire davantage de données, le système effectuait des dizaines de milliers d’opérations d’insertion et de suppression par minute.

Physiquement, les blocs de mémoire flash d’un SSD doivent être constamment effacés et réécrits pour effectuer ces opérations. De ce fait, la quantité réelle de données que la puce mémoire doit traiter est bien supérieure à la taille du fichier affichée par le système d’exploitation. C’est pourquoi cette erreur est si dangereuse pour les périphériques de stockage SSD.

Solution de contournement temporaire pour les utilisateurs

Bien qu’OpenAI ait récemment publié des mises à jour concernant la stabilité de SQLite, le problème des vitesses d’écriture de données excessivement élevées persiste. En attendant un correctif officiel, les utilisateurs de Linux et macOS peuvent appliquer la méthode suivante pour protéger leurs disques durs :

Utilisez un lien symbolique (symlink) pour rediriger le fichier ~/.codex/logs_2.sqlite vers le répertoire /tmp/ . Le répertoire /tmp/ est généralement mappé sur la RAM (tmpfs), ce qui signifie que les données de journalisation sont écrites dans la RAM au lieu du SSD. Ce fichier ne contenant pas de données de conversation critiques, la perte des données de journalisation lors du redémarrage de l’ordinateur n’affectera pas l’expérience utilisateur.

Les experts recommandent aux utilisateurs de Codex CLI de vérifier immédiatement l’activité de leurs disques et d’appliquer des mesures de redirection des données afin d’éviter tout dommage physique inutile à leurs périphériques de stockage.

Source : https://baodanang.vn/loi-openai-codex-cli-am-tham-bao-mon-ssd-nguy-co-hong-o-cung-trong-chua-day-mot-nam-3341429.html