Codex Aylarca SSD'nizi Sessizce Yıprattı ve Kimse Fark Etmedi

Küçük Dosyalar Devasa Flash Aşınmasını Nasıl Gizler?#

Codex günlük (log) dosyanız tamamen normal görünüyordu; ancak SSD sayaçlarınız aynı fikirde değildi. Dosya boyutunun küçük kalması asıl yanıltıcı noktaydı. ~/.codex/ dizinini açtığınızda logs_2.sqlite adında bir SQLite veritabanı görebilirdiniz. Diski doldurmuyor, Finder, Explorer veya du gibi standart depolama kontrollerinde hiçbir tehlike sinyali vermiyordu.

Buna karşın, bir geliştiricinin SSD'si 21 günde yaklaşık 37 TB yazma işlemi kaydetti. Bu, günde yaklaşık 1,7 TB ve aynı yoğunlukta tam bir yıla yayıldığında yaklaşık 640 TB yazma hacmi anlamına gelir. Bu sayı her Codex kullanıcısı için genel bir tahmin olmasa da yerel geliştirici araçlarında gözden kaçması çok kolay olan kritik bir mimari sorunu ortaya çıkardı: Bir dosya küçük kalırken altındaki fiziksel depolama birimi aralıksız olarak yazma işlemine maruz kalabilir. Bu olay; gürültülü bir TRACE loglama akışının, kendisine söyleneni eksiksiz yapan bir SQLite veritabanının ve yalnızca dosya boyutuna bakarak kimsenin göremediği SSD aşınmasının hikayesidir.

Özeti (Hızlı Bakış)#

Bir kullanıcı, yerel diskte olağandışı derecede yüksek yazma işlemleri fark etti ve bunları Codex CLI'ın logs_2.sqlite veritabanı ile onun WAL (Write-Ahead Logging) eşlikçi dosyasına kadar takip etti.
Raporlanan makinede 21 günlük çalışma süresi boyunca yaklaşık 37 TB yazma işlemi birikti.
Yeni loglar eklenirken eski loglar silindiği için dosya boyutu sınırlı ve sabit kaldı.
Sorunun kaynağı, beklenen RUST_LOG geçersiz kılma (override) ayarını tam olarak dikkate almayan aşırı ayrıntılı bir TRACE loglama yoluydu.
Yapılan incelemelere göre 0.142.0 sürümü gürültülü yazma işlemlerini önemli ölçüde azalttı ve ilk testlerde log yazımlarında yaklaşık %85 azalma sağlandı.
Eski bir sürümü yoğun şekilde kullandıysanız, önce aracı güncelleyin, ardından gerçek yazma etkinliğini ve SSD'nizin ömür boyu yazma sayaçlarını kontrol edin.

İnsanları İki Kez Düşündüren Rakamlar#

21 günde 37 TB veri yazılması, sıradan bir "geliştirici aracı birkaç log yazdı" vakası değildir.

Raporlanan yazma miktarı: ~37 TB
Raporlama aralığı: 21 gün
Yaklaşık günlük oran: ~1,7 TB/gün
Yıllıklandırılmış oran: ~640 TB/yıl

Yıllıklandırılmış sayıyı doğru bağlamda değerlendirmek gerekir. Kısa oturumlar çalıştıran bir geliştirici çok daha az veri üretecektir; ancak aracı sürekli açık bırakan, uzun oturumlarla çalışan veya otomasyon süreçlerine dahil eden biri beklediğinden çok daha fazla disk aşınması yaşayabilir. Yazılım mühendisliği açısından buradaki temel çıkarım "her SSD bir yılda bozulacak" demek değil, bu seviyedeki bir G/Ç (I/O) etkinliğinin mutlaka izlenmesi ve kontrol altına alınması gerektiğidir.

Dosya Boyutu Neden Neredeyse Hiçbir Şey Söylemedi?#

Çoğumuz disk sorunlarını şu temel komutlarla kontrol ederiz:

du -sh ~/.codex
ls -lh ~/.codex/logs_2.sqlite*

Bu komutlar yalnızca tek bir soruya yanıt verir: Şu anda ne kadar veri depolanıyor? Ancak şu soruyu yanıtlamaz: Zaman içinde toplam ne kadar veri yazıldı?

Codex log veritabanı, sınırlı miktarda tanılama bilgisi tutacak şekilde tasarlanmıştı. Yeni satırlar yazılıyor, eski satırlar siliniyor ve veritabanı yaklaşık olarak aynı boyutta kalıyordu. Dört masalı bir kafe düşünün: Öğlen pencereden baktığınızda dört kişi oturuyor, akşam 6'da baktığınızda yine dört kişi var. Masa sayısı size gün içinde kafeyi sekiz müşterinin mi yoksa sekiz yüz müşterinin mi ziyaret ettiğini söylemez. SQLite dosyası da tam olarak böyleydi: sabit boyut, devasa veri sirkülasyonu.

Tüm Bu Yazma İşlemlerini Ne Üretiyordu?#

Raporlanan sorun, Rust'ın tracing ekosistemindeki en ayrıntılı seviye olan TRACE düzeyine varsayılan olarak ayarlanmış bir loglama yoluna işaret ediyor. Geliştiriciler için pratik ders açıktır: Üretim veya yerel araçlarda varsayılan log seviyelerini dikkatle yapılandırmak, rotasyon (silme/ekleme) mekanizmalarının donanım üzerindeki G/Ç maliyetini ölçmek ve sistem gözlemlenebilirliğini (observability) yalnızca disk alanı ile sınırlamamak gerekir.