Sabit disklerdeki bit çürüklüğü gerçek bir sorun mu? Bu konuda ne yapılabilir?

Bir arkadaşım benimle rasgele saygısız, veri bozucu sürücülerdeki bit çürüklüğü sorunu hakkında konuşuyor. İnanılmaz derecede nadir, ancak yeterince zaman ile bir sorun olabilir ve tespit etmek imkansızdır.

Sürücü, bunun kötü bir sektör olduğunu düşünmez ve yedekler sadece dosyanın değiştiğini düşünür. Bütünlüğü doğrulamak için hiçbir kontrol toplamı yoktur. Bir RAID kurulumunda bile, fark algılanır ancak hangi ayna kopyanın doğru olduğunu bilmenin bir yolu olmazdı.

Bu gerçek bir problem mi? Ve eğer öyleyse, bu konuda ne yapılabilir? Arkadaşım zfs'i bir çözüm olarak öneriyor, ancak dosya sunucularımızı işte düzleştirmeyi, Solaris ve zfs'i takmayı hayal edemiyorum.

Öncelikle: Dosya sisteminizde sağlama toplamı olmayabilir, ancak sabit sürücünüzün kendisi vardır. Örneğin, SMART var. Bir bit çok fazla çarptığında, hata elbette düzeltilemez. Ve eğer gerçekten şanssızsanız, bitler, sağlama toplamı geçersiz olmayacak şekilde değişebilir; o zaman hata bile algılanmaz. Böylece, kötü şeyler olabilir ; ancak rastgele bir bit saygısız anında anında veri bozucu olacağı iddiası sahte.

Ancak, evet, sabit bir sürücüye trilyonlarca bit koyduğunuzda sonsuza dek böyle kalmazlar; bu gerçek bir problem! ZFS, verilerin her okunuşunda bütünlük kontrolü yapabilir; bu, sabit sürücünüzün zaten yaptığı şeye benzer, ancak bazı alanlardan fedakarlık yaptığınız başka bir korumadır, bu nedenle veri bozulmalarına karşı dayanıklılığı artırırsınız.

Dosya sisteminiz yeterince iyi olduğunda, algılanmadan meydana gelen bir hatanın olasılığı o kadar düşük olur ki, artık bunu umursamamanız gerekebilir ve kullandığınız veri depolama biçiminde yerleşik sağlama toplamı olduğuna karar verebilirsiniz gereksiz.

Her iki durumda: hayır, tespit edilmesi imkansız değil .

Ancak, bir dosya sistemi tek başına her hatanın giderilebileceğinin bir garantisi olamaz; Gümüş bir mermi değil. Bir hata tespit edildiğinde ne yapılması gerektiğine dair hala yedeklemeler ve bir plan / algoritma olmalıdır.

Evet, esas olarak sürücü boyutları arttıkça bir problemdir. Çoğu SATA sürücü, 10 ^ 14 değerinde bir ÜRE (düzeltilemez okuma hatası) oranına sahiptir. Veya her 12 TB veri için istatistiksel olarak okuyun, sürücü satıcısı, sürücünün bir okuma hatası vereceğini söylüyor (normalde bunları sürücü özellik sayfalarına bakabilirsiniz). Sürücü, sürücünün diğer tüm parçaları için gayet iyi çalışmaya devam edecektir. Enterprise FC ve SCSI sürücüsü, azaltmaya yardımcı olan az sayıda SATA sürücüsü ile birlikte genellikle 10 ^ 15 (120 TB) URE hızına sahiptir.

Disklerin aynı anda dönmeyi bıraktıklarını hiç görmedim, ancak bu sayıya 5 baskın önce 5400 RPM tüketici PATA sürücülerle baskın basmıştım. Sürücü arızalı, ölü olarak işaretlenmiş ve yedek sürücüye yeniden bir onarım gerçekleşmiştir. Sorun yeniden oluşturma sırasında ikinci bir sürücünün o küçük bir veri bloğunu okuyamadığıdır. Baskın yapanlara bağlı olarak, tüm hacim ölü olabilir veya sadece o küçük blok ölebilir. Sadece bir bloğun öldüğünü varsayarsak, okumaya çalışırsanız bir hata alırsınız, ancak eğer yazarsanız sürücü başka bir yere yeniden gönderir.

Karşı korunmanın birçok yöntemi vardır: çift disk arızasına karşı koruyan raid6 (veya eşdeğeri) en iyisidir, ek olanlar ZFS gibi URE uyumlu bir dosya sistemidir, böylece daha küçük baskın grupları kullanarak URE sürücüsüne çarpma şansınız daha düşüktür limitleri (büyük sürücüleri veya baskın 5 küçük sürücüleri yansıtır), disk fırçalamayı ve SMART da yardımcı olur ancak kendi başına bir koruma değildir, ancak yukarıdaki yöntemlerden birine ek olarak kullanılır.

Dizilerde 3000'e yakın iğ yönetiyorum ve diziler sürekli olarak gizli URE'leri arayan sürücüleri temizliyor. Ve oldukça sabit bir akışını alıyorum (her bululduğunda, sürücü arızasından önce düzeltir ve beni uyarır), eğer baskın6 yerine raid5 kullanıyor olsaydım ve sürücülerden biri tamamen öldü ... Belli yerlere vurursa başını belaya sokar.

Sabit sürücüler genellikle tek bir manyetik alan olarak veri bitlerini kodlamaz - sabit sürücü üreticileri her zaman manyetik alanların dönebileceğinin farkındadır ve sürücülerde hata algılama ve düzeltme oluşturabilir.

Bir bit dönerse, sürücü bir sonraki okunduğunda okuyabileceği ve düzeltileceği yeterince fazla veri içerir. Bunu, sürücüdeki SMART istatistiklerini 'Düzeltilebilir hata oranı' olarak işaretlerseniz görebilirsiniz.

Sürücünün detaylarına bağlı olarak, bir sektörde birden fazla çevrilmiş bitten bile kurtulabilmesi gerekir. Sessizce düzeltilebilecek çevirilmiş bitlerin sayısında bir sınır olacak ve muhtemelen bir hata olarak tespit edilebilecek çevirilmiş bitlerin sayısında bir sınır olacaktır (düzeltmek için artık yeterince güvenilir veri olmasa bile)

Bunların hepsi, sabit sürücülerin çoğu hatayı otomatik olarak düzeltebildikleri ve geri kalanların çoğunu güvenilir bir şekilde tespit edebildikleri gerçeğini ekler. Tek bir sektörde, tümü o sektör tekrar okunmadan önce gerçekleşen çok sayıda bit hatasına sahip olmanız ve hataların, iç hata saptama kodlarının sizden önce geçerli veriler olarak görmesini sağlayacak şekilde olması gerekirdi. hiç sessiz bir başarısızlığa sahip olurdu. İmkansız değil, ben çok büyük veri merkezleri faaliyet gösteren şirketler gerçekleşmesi (daha doğrusu, bu gerçekleşir ve gördükleri emin değilim yok gerçekleşmesi bakınız), ancak düşündüğünüzden kadar büyük bir sorun olarak kesinlikle değil.

Modern sabit disklerde (199x'ten beri) sadece sağlama toplamı değil, aynı zamanda oldukça "rasgele" bir bit rotası tespit edip düzeltebilen ECC de var. Bakınız: http://en.wikipedia.org/wiki/SMART .

Öte yandan, bellenim ve aygıt sürücülerindeki bazı hatalar da nadiren (aksi halde QA hataları yakalar) durumlarda verileri bozabilir, bu da daha yüksek düzeyde sağlama toplamına sahip olmadığınız takdirde tespit edilmesi zor olacaktır. SATA ve NIC'lerin ilk aygıt sürücüleri hem Linux hem de Solaris'teki verileri bozmuştur.

ZFS sağlama toplamları çoğunlukla düşük seviye yazılımlardaki hataları hedef alır. Hypertable gibi daha yeni depolama / veritabanı sistemi, dosya sistemlerinde hatalara karşı korunmak için her güncellemenin sağlama toplamına sahiptir :)

Teorik olarak, bu endişe nedenidir. Pratik olarak konuşursak, bu çocuk / ebeveyn / büyükbaba yedeklerini saklama nedenimizin bir parçasıdır. Yıllık yedeklemelerin IMO için en az 5 yıl tutulması gerekir ve bunun bundan daha geriye gitme ihtimalinin olması durumunda, dosya açıkça o kadar önemli değil.

Birisinin beynini sıvılaştırma potansiyeli olan bitlerle başa çıkmadığınız sürece , riske karşı riskin dosya sistemlerini değiştirme noktasına bağlı olduğundan emin değilim.

Evet bu bir problem.

Bu, RAID6'nın şu anda moda olmasının nedenlerinden biri (artan HD boyutlarının yanı sıra bir diziyi yeniden oluşturma süresini artırması). İki parite bloğuna sahip olmak ek bir yedeklemeye izin verir.

RAID sistemleri artık periyodik olarak disk bloklarını okuyan, paritelere karşı kontrol eden ve hatalı bir blok bulursa değiştiren RAID Ovma işlemini de yapıyor.

OP'nin RAID ile ilgili ifadesine gelince, hangi verinin iyi veya kötü olduğunu anlamadığı için.

RAID denetleyicileri, her veri şeridi üzerinde en az (tek / çift) eşitlik bit kullanır. Bu her şey için; disk üzerindeki veriler ve parite (yedek) veri şeritleri.

Bu, yedeklilik için şeritleme özelliğine sahip herhangi bir RAID türü için (RAID 5/6), kontrol cihazının, orijinal veri şeridinin değişip değişmediğini ve yedeklilik veri şeridinin değişip değişmediğini doğru bir şekilde anlayabileceği anlamına gelir.

RAID6 gibi ikinci bir yedek şerit tanıtırsanız, hepsi aynı gerçek dosya verisine karşılık gelen üç farklı sürücüde 3 veri şeridine sahip olmalısınız. Çoğu RAID sisteminin nispeten küçük veri şeritleri (128kb veya daha az) kullandığını ve bu nedenle aynı dosyanın aynı 128kb'a kadar olan "bit çürüklüğünün" şansının pratikte imkansız olduğunu unutmayın.

Bu gerçek bir dünya problemi, evet, ama soru şu, bu konuda endişelenip endişelenmemelisin.

Sadece resimlerle dolu bir hdd varsa bu çabaya değer olmayabilir. Önemli bilimsel verilerle doludur, başka bir hikaye olabilir, fikrin var.