خلل في OpenAI Codex CLI قد يسبب تآكل أقراص SSD بسبب التسجيلات التشخيصية المفرطة
يتناول المقال خللاً في OpenAI Codex CLI قد يؤدي إلى زيادة كبيرة في كتابة البيانات على أقراص SSD بسبب تسجيل تشخيصي مفرط.
تم الإبلاغ عن المشكلة لأول مرة في 14 يونيو من قِبل مستخدم معروف باسم 1996fanrui، حيث لاحظ معدلات كتابة عالية بشكل غير عادي أثناء استعمال Codex CLI. كما يبدو أن تقارير مماثلة ظهرت منذ أبريل، ما يوحي بأن المشكلة قد تكون مطروحة منذ عدة أشهر.
تشير المصادر إلى أن الكتابة الزائدة تنشأ من قاعدة بيانات SQLite محلية تقع عند المسار ~/.codex/logs_2.sqlite، وتستمر في تسجيل معلومات تشخيصية يولّدها التطبيق.
هناك تقارير تفيد بأن الكتبات وصلت إلى نحو 37 تيرابايت خلال 21 يوماً. وإذا استمر هذا المعدل لمدة عام كامل، فسيبلغ مجمل الكتابة نحو 640 تيرابايت سنوياً. وللمقارنة، تحمل العديد من أقراص SSD سعة 1 تيرابايت تصنيفات تحملها عادة نحو 600 تيرابايت مكتوبة خلال عمرها المتوقع. وتختلف قدرة التحمل حسب النموذج والشركة المصنعة، لكن نشاط الكتابة المستمر بهذا المستوى قد يسرّع تآكل الأقراص المصابة.
المسبب الجذري يبدو أن ‘SQLite feedback sink’ في Codex يعمل عند مستوى TRACE بشكل افتراضي، وهو أعلى مستوى تسجيل تفصيلي. TRACE يسجّل كميات كبيرة من معلومات التشخيص. وتُشير التقارير إلى أن السجلات تتضمن بيانات WebSocket خام ووقائع نظام الملفات وتليمزيات منخفضة المستوى لا جدوى كبيرة لها لمعظم المستخدمين أثناء التشغيل العادي.
كما أُشير إلى أن أنظمة التحكم في التسجيل لا تعمل كما ينبغي، إذ يبدو أن متغير البيئة RUST_LOG يُتجاهل في كثير من الأحيان، مما يصعِّب تقليل مستوى التسجيل بشكل يدوي. وتشير التحليلات إلى أن نحو 71% من البيانات المسجَّلة هي ضوضاء تُصنَّف إلى TRACE. وعلى الرغم من فائدة هذه التفاصيل عند استكشاف أخطاء محددة، فهي غالباً غير ضرورية للاستخدام اليومي.
وتسهم أنماط كتابة SQLite في زيادة التأثير، فالتكرار في عمليات الإدراج والحذف يمكن أن يولّد عددًا أكبر من عمليات الكتابة الفعلية مقارنة بحجم قاعدة البيانات النهائي، وهو ما يُعرف بتضخيم الكتابة. ونتيجة لذلك، قد يكون التآكل الفعلي للتخزين أعلى مما يُتوقع عند الاعتماد فقط على حجم ملف القاعدة.
لم تُحل المشكلة نهائياً في التحديثات الأخيرة؛ إذ أُطلقت تحديثات من قِبل مطوري Codex أشارت إلى تحسينات موثوقية لـ SQLite، لكن التقارير تقر بأن هذه التحديثات لم تعالج معدل الكتابة المفرط. حتى وقت كتابة هذه السطور، بقيت المسألة مفتوحة. كحل مؤقّت لمستخدمي لينكس وmacOS، يمكن توجيه قاعدة البيانات ~/.codex/logs_2.sqlite إلى /tmp/ بحيث تُخزَّن الكتابة في ذاكرة الوصول العشوائي بدلاً من SSD. مع ذلك، سيُفقد سجل البيانات عند إعادة التشغيل.
