mdadm ile bit çürümesi algılama ve düzeltme

Tüm HDD'lerimi ev linux kutusu nas'mda yeniden düzenlemek üzereyim ve veri koruma ve dizileri yeniden şekillendirme esnekliği için mdadm raid kullanmak istiyorum. Ancak, bunun için mdadm'ı kullanmadan önce, biraz çürümeyi nasıl ele aldığını bilmek istiyorum . Özellikle, HDD'den kurtarılamayan okuma hatası mesajlarının gönderilmesine neden olmayan bit çürümesi türleri.

Ben 8 nas ve diskler üzerinde çeşitli tırnak içinde HDD'ler en az 21TB kullanarak olasılıkla edeceğiz düşünüldüğünde olasılıklar arasında başarısızlıkları HDD'lerde, ben bir tek disk arızası yeniden sırasında ben karşılaşma olasılığı oldukça olduğum düşünme değilim geri kalan disklerde bir çeşit bit çürümesi. Sürücülerin 1'inde kurtarılamayan bir okuma hatasıysa, sürücünün aslında bir hata olarak rapor ettiğini, raid6 ile iyi olması gerektiğine inanıyorum (öyle mi?). Ancak diskten okunan veriler kötü ise, ancak disk tarafından rapor edilmezse, raid6 ile bile bunun nasıl otomatik olarak düzeltilebileceğini göremiyorum. Bu endişelenmemiz gereken bir şey mi? Bu 2010 ve RAID5 hala çalışıyor makalesi verildive evde ve işte yaptığım kendi başarılı deneyimlerim, her şeyin vızıltı sözcükleri ve pazarlamanın bize inandığı gibi kıyamet ve kasvet olması gerekmez, ancak bir HDD'nin başarısız olması nedeniyle yedeklerden geri yüklemek zorunda kalmaktan nefret ederim.

Kullanım örüntüleri olacağı, en fazla birkaç kez yazılacağı ve ara sıra okuyacağı göz önüne alındığında, veri temizlemesi yapmam gerekecek . Ben archlinux wiki bir dizi olarak veri ovma için mdadm komutları görüyorum

echo check > /sys/block/md0/md/sync_action

sonra ilerlemeyi izlemek için

cat /proc/mdstat

Bana öyle geliyor ki, tüm disklerin tüm sektörlerini okuyacak ve verilerin parite ile eşleşip eşleşmediğini kontrol edecektir. Belgelerde, "kontrol" işleminin otomatik olarak düzeltemeyeceği, yalnızca algılayamayacağı ve düzeltilmesi için kullanıcıya bırakacağı önemli durumlar olduğunu söylemek için ağır bir vurgu olduğunu fark etsem de.

Bit çürümesine karşı korumamı en üst düzeye çıkarmak için hangi mdadm RAID düzeylerini seçmeliyim ve hangi bakım ve diğer koruyucu adımları yapmalıyım? Ve bu beni neyden koruyamayacak?

Düzenleme: Bir RAID vs ZFS veya başka bir teknoloji QA başlatmak istemiyorum. Özellikle mdadm baskını hakkında bilmek istiyorum. Bu yüzden SuperUser'da değil Unix ve Linux'ta soruyorum .

Düzenleme: cevap: mdadm sadece bir veri ovma sırasında disk sistemleri tarafından bildirilen URE düzeltmek ve bir fırçalama sırasında sessiz bit çürüklüğü algılayabilir ama düzeltemez / düzeltmek değil mi?

Açıkçası, RAIDZ2 ZFS'yi reddetmenizi oldukça şaşırtıcı buluyorum. Linux MD olmadığı gerçeği dışında ihtiyaçlarınıza neredeyse mükemmel şekilde uyuyor gibi görünüyor . ZFS'yi kitlelere getirmek için bir haçlı seferi yapmıyorum, ancak basit gerçek şu ki, ZFS'nin sıfırdan çözmek için tasarlandığı sorunlardan biri . Muhtemelen azaltılmış veya artıksızlık durumunda hata algılama ve düzeltme sağlamak için RAID'e (herhangi bir "normal" RAID) güvenmek riskli görünmektedir. ZFS'nin bir veri hatasını düzgün bir şekilde düzeltemediği durumlarda bile , en azından hatayı algılayabilir ve bir sorun olduğunu bildirerek düzeltici önlem almanıza izin verebilir.

Sen yok olması o uygulama önerilir rağmen, ZFS ile düzenli tam önlük yapmak. ZFS, diskten okunan verilerin, veri okunurken yazılanlarla eşleştiğini doğrular ve uyumsuzluk durumunda (a) orijinal verileri yeniden oluşturmak için artıklık kullanın veya (b) uygulama. Ayrıca, ovma, düşük öncelikli, çevrimiçi bir işlemdir ve çoğu dosya sisteminde hem yüksek öncelikli hem de çevrimdışı olabilen bir dosya sistemi denetiminden oldukça farklıdır. Bir ovma çalıştırıyorsanız ve ovma dışında bir şey I / O yapmak istiyorsa, ovma süresi arka koltuğu alacaktır. Bir ZFS bodur bir RAID kese hem gerçekleşir ve bir dosya sistemi meta ve veri bütünlük kontrolü, bu yüzden herhangi bir bit çürümesini tespit etmek için RAID dizisini ovmaktan çok daha ayrıntılıdır (bu, verilerin herhangi bir anlam ifade edip etmediğini söylemez, sadece RAID denetleyicisi tarafından doğru bir şekilde yazıldığını gösterir).

ZFS artıklığı (RAIDZ, yansıtma, ...), kullanılmayan disk konumlarının fırçalama sırasında tutarlılık açısından kontrol edilmesine gerek olmaması avantajına sahiptir; araçlar tahsis blok zincirinde yürüdükleri için sadece gerçek veriler fırçalama sırasında kontrol edilir. Bu, yedekli olmayan bir havuzdakiyle aynıdır. "Normal" RAID için, RAID denetleyicisinin (donanım veya yazılım) gerçekte hangi verilerin gerçekte alakalı olduğu hakkında hiçbir fikri olmadığı için tüm veriler (diskteki kullanılmayan konumlar dahil) kontrol edilmelidir.

RAIDZ2 vdevs kullanarak, herhangi bir iki bileşen sürücüsü, iki sürücünün yedekli değeriniz olduğundan, başka bir sürücü arızasından gerçek veri kaybı riskiyle karşılaşmadan önce başarısız olabilir. Bu aslında RAID6 ile aynıdır.

ZFS'de, hem kullanıcı verileri hem de meta verilerdeki tüm veriler kontrol toplamına alınır (seçilmemesi, ancak buna karşı yapılması önerilmediği durumlar hariç) ve bu sağlama toplamları verilerin herhangi bir nedenle değişmediğini doğrulamak için kullanılır. Yine, bir sağlama toplamı beklenen değerle eşleşmezse, veriler ya şeffaf bir şekilde yeniden yapılandırılacak ya da bir G / Ç hatası rapor edilecektir. Bir G / Ç hatası bildirilirse veya bir fırçalama bozuk bir dosyayı tanımlarsa, o dosyadaki verilerin potansiyel olarak bozuk olduğunu ve söz konusu dosyayı yedeklemeden geri yükleyebileceğini bilirsiniz; tam dizi geri yüklemesine gerek yok.

Düz, çift eşlikli RAID, örneğin bir sürücü arızalandığında ve bir diğeri verileri diskten yanlış okuduğunda olduğu gibi durumlara karşı sizi korumaz. Bir sürücünün başarısız olduğunu ve diğer sürücülerin herhangi birinden tek bir bit döndüğünü varsayalım: aniden, fark edilmeyen yolsuzluğunuz var ve bundan memnun değilseniz, en azından tespit etmenin bir yoluna ihtiyacınız olacak. Riski azaltmanın yolu, diskteki her bloğu sağlama toplamı yapmak ve sağlama toplamının verilerle birlikte bozulmayacağından emin olmaktır (yüksek sinirli yazma, yetim yazma gibi hatalara karşı koruma, diskteki yanlış konumlara yazma vb.). sağlama toplamı etkin olduğu sürece ZFS'nin yaptığı tam olarak budur.

Tek gerçek dezavantajı, bir RAIDZ vdev'i cihaz ekleyerek kolayca büyütememenizdir. Bunun için geçici çözümler vardır, genellikle vdev'deki cihazlar olarak seyrek dosyalar gibi şeyleri içerir ve sıklıkla "Verilerim olsaydı bunu yapmazdım" olarak adlandırılır. Bu nedenle, bir RAIDZ yoluna giderseniz (RAIDZ, RAIDZ2 veya RAIDZ3 ile gidip gitmediğinize bakılmaksızın), her vdev'de kaç sürücü istediğinize karar vermeniz gerekir. Bir vdev içinde sürücü sayısı sabittir rağmen, olabilir tedricen (vdev fazlalığı eşiği içinde kalmak emin olarak) daha büyük kapasiteli olanlarla diskler yerine ve tam bir resilver izin vererek bir vdev büyür.

Bu cevap, bulduğum çeşitli kanıt parçalarına dayanan akıl yürütmenin ürünüdür. Çekirdek Linux uygulamasının nasıl çalıştığını bilmiyorum, çünkü bir çekirdek geliştiricisi değilim ve orada oldukça fazla saçma sapan bilgi var gibi görünüyor. Çekirdek Linux'un aklı başında seçimler yaptığını düşünüyorum. Yanılmıyorsam cevabım geçerli olmalı.

Birçok sürücü, okuma hatalarını tespit etmek için ECC'leri (hata düzeltme kodları) kullanır. Veriler bozuksa, çekirdek ECC destekli bir sürücüden bu blok için bir URE (kurtarılamaz okuma hatası) almalıdır. Bu koşullar altında (ve aşağıda bir istisna söz konusudur), bozuk veya boş verilerin kopyalanması iyi veriler üzerinden delilik anlamına gelir. Bu durumda çekirdek hangisinin iyi, hangisinin kötü veri olduğunu bilmelidir. Göre O 2010 ve RAID5 hala ... işleri madde:

En azından birkaç dizi satıcısı tarafından kullanıldığını bildiğim bu alternatifi düşünün. RAID birimindeki bir sürücü bir URE bildirdiğinde, dizi denetleyicisi sayımı artırır ve bloğu eşlikten yeniden oluşturarak G / Ç'yi tatmin eder. Daha sonra, URE'yi (potansiyel olarak doğrulama ile) bildiren diskte yeniden yazma yapar ve sektör kötü ise, mikro kod yeniden eşlenir ve hepsi iyi olur.

Ancak şimdi istisna için: bir sürücü ECC'yi desteklemiyorsa, bir sürücü veri bozulması hakkında ya da bellenim özellikle işlevsizse, bir URE raporlanmayabilir ve çekirdeğe bozuk veriler verilebilir. Verilerin uyuşmaması durumunda: 2 diskli bir RAID1 veya bir RAID5 kullanıyorsanız, çekirdek, bozulmamış bir durumda bile hangi verilerin doğru olduğunu bilemez, çünkü yalnızca bir parite var blok ve bildirilen URE yoktu. 3 diskli bir RAID1 veya RAID6'da, URE ile işaretlenmemiş tek bir bozuk blok yedekli eşlikle eşleşmez (diğer ilişkili bloklarla birlikte), bu nedenle uygun otomatik kurtarma mümkün olmalıdır.

Hikayenin ahlakı: ECC ile sürücüler kullanın. Ne yazık ki ECC'yi destekleyen tüm sürücüler bu özelliği tanıtmaz. Öte yandan, dikkatli olun: 2 diskli RAID1 (veya 2 kopyalı RAID10) içinde ucuz SSD kullanan birini tanıyorum. Sürücülerden biri, belirli bir sektörün her okumasında rasgele bozuk veriler döndürdü. Bozuk veriler otomatik olarak doğru verilerin üzerine kopyalandı. SSD ECC kullanıyorsa ve düzgün çalışıyorsa, çekirdek uygun düzeltici eylemi gerçekleştirmiş olmalıdır.

İstediğiniz koruma için, RAID6 + 2 konumdaki normal saha dışı yedeklemeyle giderdim.

Zaten haftada bir kez kişisel olarak ovuyorum ve veri önemine ve hızına bağlı olarak gece, haftalık ve aylık yedekleme yapıyorum.

Yorum yapmak için yeterli temsilcim yok, ancak Linux'taki mdadm sisteminin herhangi bir hatayı düzeltmediğini belirtmek istiyorum. Bir RAID6 ovma işlemi sırasında hataları düzeltmesini söylerseniz, tutarsızlık varsa, veri bölümlerinin doğru olduğunu ve pariteyi yeniden hesapladığını varsayarak bunu düzeltir.

biraz çürük fud.? Elbette...

Sanırım SEAGATE ile konuşmalısın. (unutmak mı? Bu bahane mi?) şimdi sürücülerin hepsi çürümeyi kanıtlamak için 100bit ECC düzeltmesine sahip.
Eminim yapamazsın. (endişe etmek FUD şey değil mi?) hayalet korkusu veya # 13 gibi? ve burada yapılmadı. sıfır kanıtı oldu. ve daha kötüsü sebep kanıtı yok.

Önce bit çürümesinin ne anlama geldiğini tanımlayın. ouch ... HDD: ECC, verileri (1 bit bile) ECC 100 bit depolama alanına göre kontrol eder. yanlışsa, düzeltir, eğer SMART motorunu arızalamaya devam ederse, SAS sürücülerinde, mantıksal olarak kümeyi veya sektörü iyi olanla değiştirir. yedek kümeler kullanarak. bu hasarı onarır. Evet, tüm sürücüler ilk günden IBM'e ilk sürücülerden ŞİMDİ'ye kadar kötü bitler çıkarıyor. ama şimdi kendi kendine onarım yapıyoruz, Seagate teknik raporlarının tamamını okuyun. ve bir sürücünün nasıl çalıştığını öğrenin. tamam?

bu yedek parça bitene kadar devam eder, (hdd beyin, akıllı) ve sonra SMART YAŞAM SONU bağırır. (veya HP'nin yaptığı gibi daha da erken), bir HP P420 denetleyici, bunu her zaman izler. Benim bile YEDEK YEDEK Kümeleri göstererek bana e-posta gönderir. Bir zamanlar yedek parçalar daha hızlı gider, yakında kıyametin kesin bir işareti, (10 yaşında sas emin, junky sata'da daha az.

Biraz çürümeye BOGUS ve FUD diyorum.

Benim tahminime göre oyuncak PC veri nedense yanlış yazdı. ECC belleği çalışmıyor ?? Hata! Gerçek sunucularda ECC RAM var. virüs bulaşmış. ya da yazma sırasında güç kaybı (UPS yok?)? ya da hafızası kötü.? veya ESD hasar görmüş. Ya da PSU tonlarca gürültü yapıyor (kötü)

Buraya FUD diyorum. afedersiniz,