Kalıcı Yazmanın Dayanıklılık Sınırları: fsync, Dizin Eşitleme, Günlükleme ve Aygıt Önbelleği

Bir dosyayı geçici adla yazdığınızı, fsync() çağırdığınızı ve ardından rename() ile hedef ada taşıdığınızı düşünün. İşlem başarıyla döndüğünde dosya kullanıcıya doğru adla görünebilir. Buna rağmen ani güç kaybından sonra aynı adın veya son içeriğin korunacağından emin olmak için yalnızca bu gözlem yeterli değildir.

Kalıcı yazmada asıl güçlük, görünürlük ile dayanıklılığın farklı katmanlarda sağlanmasıdır.

Dosya doğru görünüyor; peki gerçekten kalıcı mı?

Atomic rename, aynı dosya sistemi içinde ad değişikliğinin gözlemcilere yarım bir durum göstermemesini sağlayabilir. Bu, ad alanı açısından atomikliktir.

fsync() ise dosyaya ait kirli veri ve gerekli metaverinin kalıcı depolama yoluna gönderilmesini ister. Ancak yeni bir dosya adı oluşturulduğunda veya dizin girdisi değiştiğinde yalnızca dosyanın kendisini eşitlemek her dosya sistemi ve hata senaryosu için yeterli kabul edilmemelidir. Dizin girdisinin de kalıcılık sınırına dahil edilmesi gerekebilir.

Bu nedenle güvenli yazma işlemi tek bir çağrıdan çok bir sıra olarak düşünülmelidir:

1. geçici dosyayı oluştur,
2. içeriği yaz,
3. dosyayı fsync() ile eşitle,
4. rename() ile hedef ada geçir,
5. gereken platformlarda üst dizini de fsync() ile eşitle.

Her uygulama bu dizinin tamamına ihtiyaç duymaz; ancak hangi adımın hangi garantiyi sağladığı bilinmeden bir adımı çıkarmak doğru değildir.

Günlükleme neyi çözer, neyi çözmez?

Journaling kullanan bir dosya sistemi çökme sonrasında dosya sistemi yapısının tutarlı biçimde toparlanmasına yardımcı olur. Bu mekanizma uygulamanın son yazdığı her baytın mutlaka kalıcı olduğu anlamına gelmez.

Günlük; metaveri, veri veya ikisini farklı biçimlerde ele alabilir. Dosya sisteminin çalışma modu da davranışı etkileyebilir. Dolayısıyla “journaling var, veri kaybolmaz” biçimindeki genelleme teknik olarak fazla güçlüdür.

Türkçede burada günlükleme ifadesini kullanmak daha doğru olsa da journal, Linux dosya sistemi araçlarında ve belgelerinde doğrudan geçen bir terim olduğu için ilk geçtiği yerde birlikte düşünmek yararlıdır.

İşletim sisteminden sonra bir katman daha vardır

fsync() çağrısının başarıyla dönmesi depolama zincirindeki bütün fiziksel katmanların aynı dayanıklılık özelliğine sahip olduğunu garanti etmez. Disk veya SSD denetleyicisinin yazma önbelleği, güç kaybı koruması ve flush/FUA davranışı sonucu etkileyebilir.

Bu yüzden dayanıklılık zinciri kabaca şöyledir:

uygulama → çekirdek → dosya sistemi → blok katmanı → denetleyici → aygıt.

Bir katmanın “tamamlandı” demesi, alt katmanın hangi garantiyi verdiği bilinmeden tek başına yeterli değildir.

NFS'de yerel disk varsayımları taşınamaz

Ağ dosya sistemlerinde istemci ile sunucu arasına başka bir dayanıklılık sözleşmesi girer. NFS protokolünde kararlı ve kararsız yazma ayrımı, COMMIT işlemi ve sunucunun verdiği garantiler önem kazanır.

Yerel fsync() davranışını doğrudan ağ üzerindeki her depolama düzenine genellemek bu nedenle risklidir. Özellikle istemci önbelleği, sunucu önbelleği ve fiziksel depolama ayrı ayrı ele alınmalıdır.

Hangi hataya karşı tasarım yapılıyor?

Dayanıklılık tartışması ancak hata modeli açıkça tanımlandığında anlamlı olur. Şu durumlar aynı problem değildir:

• uygulama sürecinin çökmesi,
• işletim sisteminin kernel panic ile durması,
• makinenin aniden güç kaybetmesi,
• depolama denetleyicisinin arızalanması,
• NFS istemci veya sunucu bağlantısının kesilmesi.

Bir yöntemin süreç çökmesine dayanması, güç kaybına veya donanım arızasına karşı aynı güvenceyi verdiği anlamına gelmez.

Bu yüzden kalıcı yazmayı “bir API çağrısı yaptım ve bitti” şeklinde değil, katmanlar arası bir dayanıklılık protokolü olarak değerlendiriyorum. Atomiklik, görünürlük ve kalıcılık birbirine yakın kavramlardır; fakat aynı garanti değildir. Dosya işlemede atomik yayınlama bu ayrımın uygulama tarafındaki tamamlayıcı örneğini oluşturur.