Engelli SATA sürücülerde yazma önbelleği güvenliği

Son zamanlarda SATA sürücüleri ile ilgili önbellek yazma, NCQ, bellenim hataları, engeller vb. Hakkında okudum ve elektrik kesintisi durumunda verilerimi güvende tutacak en iyi ayarın ne olduğundan emin değilim.

Anladığım kadarıyla NCQ, sürücünün performansı optimize etmek için yazma işlemlerini yeniden düzenlemesine izin verirken, çekirdeği hangi isteklerin fiziksel olarak yazıldığı konusunda bilgilendirir.

Yazma önbelleği sürücünün çok daha hızlı bir istekte bulunmasını sağlar, çünkü verilerin fiziksel diske yazılmasını beklemez.

Nasıl NCQ ve Write cache mix burada emin değilim ...

Dosya sistemleri, özel olarak dergiler, belirli bir isteğin ne zaman yazıldığından emin olmalıdır. Ayrıca, kullanıcı alanı işlemi belirli bir dosyanın sifonunu zorlamak için fsync () kullanır. Dosya sistemi verilerin diske yazıldığından emin olana kadar bu fsync () çağrısı geri dönmemelidir.

Yalnızca SAS sürücülerinde gördüğüm, sürücüyü önbelleği atlamaya ve doğrudan diske yazmaya zorlayan bir özellik (FUA, Force Unit Access) var. Diğer her şey için, çekirdek tarafından sürücüde önbellek sifonunu tetikleyebilen bir mekanizma olan yazma engelleri vardır. Bu, tüm önbelleği yalnızca kritik verileri değil, yazılmaya zorlar , böylece fsync () ile kötüye kullanılması durumunda tüm sistemi yavaşlatır.

Daha sonra bellenim hataları olan veya veri fiziksel olarak yazıldığında kasıtlı olarak yatan sürücüler var.

Bunu söyledikten sonra, sürücüleri / dosya sistemlerini kurmanın birkaç yolu vardır: A) NCQ ve Yazma önbelleği devre dışı B) Sadece NCQ etkin C) Sadece Önbellek yazma etkin D) Hem NCQ hem de yazma önbelleği etkin

Engelleri etkin sayıyorum .. BTW, gerçekten etkin olup olmadığını nasıl kontrol edebilirim?

Güç kaybı durumunda, diske aktif olarak yazarken, tahminim B seçeneği (NCQ, önbellek yok) hem dosya sistemi günlüğü hem de veriler için güvenlidir. Bir performans cezası olabilir.

Bariyer veya FUA kullanılıyorsa, seçenek D (NCQ + önbellek) dosya sistemi günlüğü ve fsync () kullanan uygulamalar için güvenli olacaktır. Önbellekte bekleyen veriler için kötü olurdu ve bunu tespit etmek (sağlama toplamı) dosya sistemine bağlıdır ve en azından dosya sistemi (umarım) kararsız bir durumda olmayacaktır. Performans açısından, daha iyi olmalı.

Ancak sorum şu, bir şey eksik mi? Dikkate alınacak başka bir değişken var mı? Bunu doğrulayabilecek ve sürücülerimin olması gerektiği gibi davrandığı bir araç var mı?

Doğrudan Kurumsal sistemler için, başka bir önbellek katmanının bulunduğu depolama bağdaştırıcısı (hemen hemen her zaman bir RAID kartı) şeklinde ek bir katman vardır. Bu günlerde depolama yığınında çok fazla soyutlama var ve bunu G / Ç'nizi Biliyorum adlı bir blog dizisinde derin ayrıntılara girdim .

RAID kartları, bazıları bu özelliği RAID BIOS'ta değiştirmeye bile izin veren disk üzerindeki önbelleği atlayabilir. Bu, Enterprise disklerin Enterprise olmasının bir nedenidir , ürün yazılımı tüketici sürücülerinin ( özellikle 'yeşil' sürücüler) izin vermediği şeylere izin verir . Bu özellik, endişelendiğiniz durumu doğrudan ele alır: önerilmeyen yazma işlemlerinde elektrik kesintisi. Pil veya flash destekli olması gereken RAID kart önbelleği, güç geri gelene ve bu yazma önerileri alınana kadar korunur.

Bazı kurumsal SSD'ler, gücü tamamen kapatmadan önce yerleşik önbelleği yürütmek için yeterli oomph içeren bir yerleşik kapasitör içerir.

Doğrudan anakarta bağlı diskleri olan bir sistemle çalışıyorsanız, daha az güvence vardır. Disklerin kendileri yazma önbelleği işleme yeteneğine sahip olmadıkça, bir güç kesintisi gerçekten de kayba neden olacaktır. Xfs nedeniyle sadece bu başarısızlık modu hayatta 's yetersizliğine güvenilmezliğini bir üne dosya sistemini; tasarlanmış depolama sürekliliği ile tam kurumsal sistemlerde çalışacak şekilde tasarlanmıştır.

Ancak, zaman ilerledi ve XFS bundan kurtulmak için tasarlandı. Diğer büyük Linux dosya sistemleri ( ve Windows üzerindeki ntfs ) zaten bu başarısızlık modundan kurtulmak için mühendisliğe sahipti . Nasıl çalışması gerektiği, kayıp yazıların FS dergisinde görünmeyeceği ve taahhüt edilmediklerini bileceği için yolsuzluk güvenli bir şekilde tespit edilecek ve çözülecektir.

Burada bir soruna işaret ediyorsunuz: yalan söyleyen disk bellenimi. Bu durumda FS günlüğü gerçekliğe karşı yanlış bir varsayım yapmış olacak ve bir süre yolsuzluk tespit edilemeyebilir. Eşlik RAID ve ayna RAID, alınacak başka bir gizli kopya olması gerektiği için bu sorunu çözebilir. Ancak tek disk kurulumları bu çapraz kontrole sahip olmayacak, bu yüzden gerçekten hata verecek.

Çok daha fazla doğrulama (ve varsayılan iş yükü desenlerinizle karşılaştırmalı olarak test edilmiş) Enterprise sınıfı diskleri kullanarak ve depolama sisteminizi bu tür yanlışlardan kurtulabilecek şekilde tasarlayarak ürün yazılımı riskini yaşarsınız.

Dosya sistemi günlüğü, başlangıçta, sürücüye yazma önbelleği olmadığı varsayılarak, meta verilere yazma yapılmadan önce günlüğe yazmanın tamamlanmasını bekledi. Sürücü yazma önbelleği etkinleştirildiğinde, bu varsayım bozulur ve veri kaybına neden olabilir. Böylece engeller yaratıldı. Engellerle, günlük, disk yazma önbelleği kullanıyor olsa bile, günlüğe yazmanın meta verilere yazılmadan önce tamamlanmasını sağlayabilir. Disk sürücüsü katmanında, sürücü bir Iache'nin gönderilmesinden önce, sürücü bir yazma önbelleğine sahip olduğunu ve etkinleştirildiğini bildirdiğinde, bir disk önbelleğini temizlemeye zorlar. Aksi takdirde, bu gerekli değildir, bu nedenle bariyer sadece önceki IO tamamlanıncaya kadar sonraki IO'nun sürücüye verilmesini önler. NCQ, daha fazlasını vermeden önce bekleyen birden fazla isteğin beklenmesi gerekebileceği anlamına gelir.