OpenAI Codex’te, SSD’nizi bir yıldan kısa bir sürede bozabilecek bir hata var

adresindeki OpenAI’nin Codex CLI’sini kullanıyorsanız kullanıyorsanız ve uzun süre çalışır durumda bırakırsanız, SSD'niz aşırı yük altında kalabilir.

1996fanrui adlı bir GitHub kullanıcısı , 14 Haziran'da makinesinde olağandışı derecede yüksek disk aktivitesi fark ettikten sonra bu sorunu belgeledi. Araştırmalarının ardından, Codex'in yerel bir SQLite veritabanını (~/.codex/logs_2.sqlite konumunda depolanmış) tanılama günlüğü yazma işlemleriyle sürekli olarak aşırı yüklediğini tespit etti. 21 günlük çalışma süresi boyunca, sürücü yaklaşık 37 TB'lık yazma işlemi gerçekleştirmişti. Yıllık bazda hesaplandığında, bu rakam yaklaşık 640 terabayt eder. Tipik bir 1 TB'lık tüketici SSD'sinin ömrü yaklaşık 600 TBW olarak belirtilir; dolayısıyla bu hata, düzeltilmezse sürücünüzün garanti kapsamındaki tüm dayanıklılık ömrünü bir yıldan daha kısa bir sürede tüketebilir.

Sorunun kaynağı, muhtemelen hiç kimsenin son kullanıcılara sunmayı amaçlamadığı bir günlük kaydı yapılandırmasıdır. Codex’in SQLite geri bildirim havuzu, varsayılan olarak en gürültülü ayar olan genel TRACE düzeyinde çalışır. Ham WebSocket yüklerinden ‘passwd’ ve ‘ld.so.cache’ dosyalarının açılması gibi sıradan dosya sistemi olaylarına kadar her şeyi günlüğe kaydeder. Ayrıca standart RUST_LOG ortam değişkenini de yok sayar, bu nedenle bunu azaltmanın açık bir yolu yoktur. Günlüğe kaydedilen verilerin yaklaşık %71'i, en azından ortalama bir kullanıcı için gerçek bir tanılama amacı taşımayan TRACE düzeyinde gürültüdür.

Durumu daha da kötüleştiren şey ise yazma amplifikasyonudur. Veritabanı sadece büyümekle kalmıyor, aynı zamanda dakikada on binlerce ekleme ve silme işlemi döngüsünden geçiyor. Fiziksel olarak, dosya boyutunun ima ettiğinden çok daha fazlasını sürücüye yazıyor.

Bu sorun, en azından Nisan ayından beri çeşitli şekillerde biliniyordu ve yıl boyunca konuyla ilgili çok sayıda rapor sunuldu. OpenAI’nin son değişiklik günlüğünde bazı SQLite güvenilirlik düzeltmelerine değinilmiş olsa da, yazma hızı sorunu ele alınmamıştır. Sorun hâlâ çözülmemiştir.

Bu arada, Linux ve macOS kullanıcıları, yazma işlemlerini RAM'e yönlendirmek için '~/.codex/logs_2.sqlite' dosyasını '/tmp/' dizinine sembolik bağlantı olarak yönlendirebilir. Dosya herhangi bir konuşma verisi içermediğinden, yeniden başlatma sırasında kaybolması sorun teşkil etmez.