Sessiz disk hataları ve Linux değişiminin güvenilirliği


12

Anladığım kadarıyla, sabit sürücüler ve SSD'ler sürücünün içinde bazı temel hata düzeltmelerini uygular ve mdadm gibi çoğu RAID yapılandırması, bir sürücünün bir hatayı düzeltemediğinde ve çevrimdışına alınması gerektiğine karar vermek için buna bağlı olacaktır. Ancak bu, depolama alanının hata teşhisinde% 100 doğru olmasına bağlıdır. Bu böyle değildir ve iki sürücülü bir RAID-1 aynası gibi ortak bir yapılandırma savunmasız olacaktır: bir sürücüdeki bazı bitlerin sessizce bozulduğunu ve sürücünün bir okuma hatası bildirmediğini varsayalım. Bu nedenle, btrfs ve ZFS gibi dosya sistemleri, buggy sürücü yazılımlarına, glitchy SATA kablolarına vb. Güvenmemek için kendi sağlama toplamlarını uygular.

Benzer şekilde, RAM'in güvenilirlik sorunları da olabilir ve bu nedenle bu sorunu çözmek için ECC RAM'e sahibiz.

Benim sorum şu : Linux takas dosyasını iki diskli bir konfigürasyonda sürücü yazılımı tarafından yakalanmayan sessiz yolsuzluktan / bit çürümesinden korumanın standart yolu nedir (yani ana hat çekirdek sürücülerini kullanarak)? Bana öyle geliyor ki, burada uçtan uca korumadan yoksun bir yapılandırma (btrfs tarafından sağlananlar gibi) ECC RAM'in getirdiği huzuru bir şekilde olumsuz yönde etkiliyor. Yine de iyi bir yol düşünemiyorum:

  • btrfs takas dosyalarını desteklemez. Bir btrfs dosyasından bir döngü cihazı ayarlayabilir ve bunun üzerinde bir takas yapabilirsiniz. Ama bunun sorunları var:
    • Rastgele yazma işlemleri iyi sonuç vermez: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
    • Yazarken kopyalamayı devre dışı bırakma önerisi de sağlama toplamını devre dışı bırakır - böylece bu egzersizin tüm noktasını yener. Varsayımları, veri dosyasının kendi iç korumalarına sahip olduğudur.
  • Linux'ta ZFS, ZVOL'yi takas olarak kullanmasına izin veriyor, ki sanırım işe yarayabilir: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - ancak, okumamdan , ZFS normalde bellekte talep ediyor ve takasta çalışıyor -sadece uygulama anlamaya bazı çalışma gibi geliyor. Bence bu benim ilk tercihim değil. Neden sadece güvenilir bir takasın olması için bazı ağaç dışı çekirdek modülünü kullanmak zorundasınız - bu gün ve çağda bunu en modern Linux dağıtımları / çekirdekleri ile başarmanın bir yolu var mı?
  • Aslında bir Linux çekirdek posta listesinde bellek yöneticisinin kendisinde sağlama toplamlarını etkinleştirmek için yamalar içeren bir iş parçacığı vardı, tam olarak bu soruda tartıştığım nedenlerden dolayı: http://thread.gmane.org/gmane.linux.kernel/989246 - ne yazık ki, anlayabildiğim kadarıyla, yama öldü ve bana bilinmeyen nedenlerden ötürü asla yukarı akış yapmadı. Çok kötü, hoş bir özellik gibi geldi. Öte yandan, bir RAID-1'i takas ederseniz - bozulma sağlama toplamının onarım yeteneğinin ötesindeyse, bellek yöneticisinin panik yapmadan önce veya başka bir şeyden önce diğer sürücüden okumaya çalışmasını istersiniz. muhtemelen bir bellek yöneticisinin yapması gerekenin kapsamı dışındadır.

Özetle:

  • RAM, hataları düzeltmek için ECC'ye sahiptir
  • Kalıcı depolama alanındaki dosyalarda hataları düzeltmek için btrfs vardır
  • Takas mı ??? <--- bu benim sorum

1
Şifrelenmiş takasın yan etki olarak hata algılaması olmaz mı? Şifreli akış sürücüde bozulursa, şifre çözme patlar ... Sistemin nasıl tepki vereceğine dair hiçbir fikrim yok!
Stephen Kitt

Btrfs ile ilgili hiçbir deneyimim yok, ancak alıntı yaptığınız bağlantıyı okudum ve sanırım bir şeye bakıyorsunuz. Blokların dinamik olarak oluşturulduğu dosyalara, yani seyrek dosyalara atıfta bulunurlar. COW olmadan monte edilmiş özel bir brtfs bölümü oluşturabilir, istediğiniz takas boyutuyla eşleşen sıfırlarla (dd = = dev / zero) dolu bir dosya oluşturabilir ve bu dosyayı takas dosyası olarak bağlayabilirsiniz. Bunun bir performans cezasına neden olması için hiçbir neden göremiyorum.
Mart'ta Otheus

3
@Otheus performans nedenleriyle MD sadece bir cihazdan okur (daha doğru bir şekilde tüm cihazlardan okur, ancak tek bir okuma sadece bir cihaz içerir); ilgili tüm cihazların içeriğini karşılaştırabilir, ancak bu ayrı bir işlem, ovalamadır .
Stephen Kitt

2
@Otheus: Nodatacow'u ayarlamak da sağlama toplamlarını devre dışı bırakır: btrfs.wiki.kernel.org/index.php/Mount_options ... "Bu da kontrol toplamını kapatır! IOW, nodatacow nodatasum anlamına gelir." ..... döndürür ve bit çürümesi algılanamayabilir. "
James Johnston

3
@Otheus: "Son olarak, SDD olmayan disklerde, her 512 veya 1k bloğun kendisiyle ilişkilendirilmiş bir CRC'si vardır" .... true, ancak diskin dışındaki bit döndürmelerine karşı koruma sağlamaz. (ve ayrıca kapalı kaynaklı bir defalık tescilli sürücü ürün yazılımına da çok güveniyorsunuz.) Bunlar btrfs ve ZFS'nin ilk etapta var olmasının nedenleridir: temel depolama alanına güvenmezler (ya da rahatsız etmezler) kontrol toplamı ile ilk etapta). Örneğin, bazı kullanıcılar kötü SATA kablolaması ve / veya kesintili güç kaynakları nedeniyle bit döndürmeleri bildirmiştir.
James Johnston

Yanıtlar:


5

Depolama donanımının sağlama toplamları, CRC'ler ve benzeri olduğu için takastan alınan verilerin bütünlüğüne güveniriz .

Yukarıdaki yorumlardan birinde şunları söylersiniz:

doğru, ancak diskin dışındaki bit döndürmelere karşı koruma sağlamaz

"It" burada diskin sağlama toplamı anlamına gelir.

Bu doğrudur, ancak SATA komutlar ve veriler için 32 bit CRC'ler kullanır . Böylece, disk ve SATA denetleyicisi arasındaki verileri fark edilmeden bozma şansınız 4 milyarda 1'dir. Bu, sürekli bir hata kaynağının aktarılan her 125 MiB kadar sık ​​bir hataya neden olabileceği, ancak kozmik ışınlar gibi nadir, rastgele bir hata kaynağının kaybolan küçük bir oranda tespit edilemeyen hatalara neden olacağı anlamına gelir.

Ayrıca, aktarılan her 125 MiB için bir yere yakın bir oranda algılanmayan bir hataya neden olan bir kaynağınız varsa, yeniden aktarım gerektiren çok sayıda tespit edilen hata nedeniyle performansın korkunç olacağını unutmayın . İzleme ve günlük kaydı, tespit edilmeyen yolsuzluklardan kaçınmak için sizi muhtemelen sorun hakkında zamanında uyaracaktır.

Depolama ortamının sağlama toplamlarına gelince, her SATA (ve ondan önceki PATA) diski bir tür sektör başına sağlama toplamı kullanır. "Kurumsal" sabit disklerin karakteristik özelliklerinden biri, ek veri bütünlüğü özellikleriyle korunan daha büyük sektörlerdir ve tespit edilemeyen hata olasılığını büyük ölçüde azaltır.

Bu tür önlemler olmadan , her sabit diskteki yedek sektör havuzunun bir anlamı olmayacaktır : diskin kendisi kötü bir sektörü tespit edemedi, bu yüzden taze sektörleri asla değiştiremedi.

Başka bir yorumda şunları soruyorsunuz:

SATA bu kadar güvenilirse neden ZFS, btrfs, ReFS gibi sağlama toplamlı dosya sistemleri vardır?

Genel olarak, uzun vadeli verileri depolamak için takas istemiyoruz. Takas depolama sınırlaması sistemin çalışma süresidir ve takastaki verilerin çoğu, sisteminizin sanal bellek sisteminden geçen çoğu veri çok daha kısa ömürlü işlemlere ait olduğu için neredeyse o kadar uzun sürmez.

Bunun da ötesinde, yükselişler çekirdek ve libcgüncelleme sıklığı , sanallaştırma, bulut mimarileri vb. İle yıllar içinde genellikle kısalmıştır .

Ayrıca, takastaki verilerin çoğu, iyi yönetilen bir sistemde doğal olarak devre dışı bırakılır, bu da kendisini ana RAM'den tükenmez. Böyle bir sistemde, takasla sonuçlanan tek şey , programın hiç kullanmadıkları sayfalardır . Bu tahmin edebileceğinizden daha yaygın. Programlarınızın kullandığı programların kullanmadığı rutinlere sahip olduğu çoğu dinamik kütüphanenin dinamik bağlayıcı tarafından RAM'e yüklenmesi gerekiyordu . OS kütüphanede programı metnin tüm kullanmadığınızı gördüğünde, senin programların bu kodu ve veri için oda yapma bunu değiştirir edilir kullanarak. Bu tür değiştirilmiş bellek sayfaları bozuksa, kim bilebilirdi?

Bunu, verilerin kalıcı ve kalıcı bir şekilde depolanmasını beklediğimiz ZFS'nin beğenileriyle karşılaştırın, böylece sadece sistemin mevcut çalışma süresinin ötesinde değil, aynı zamanda depolama sistemini oluşturan ayrı depolama cihazlarının ömrünün de ötesinde kalır. ZFS ve benzerleri, takas ile çözülen problemden kabaca iki büyüklükte daha uzun bir zaman ölçeği ile problem çözmektedir. Bu nedenle, ZFS için Linux takasından çok daha yüksek yolsuzluk algılama gereksinimimiz var.

ZFS ve benzerleri takastan başka bir anahtar şekilde farklılık gösterir: RAID takas sistemlerini birlikte RAID yapmayız. Ne zaman birden takas cihazlar tek bir makinede kullanılmakta olan, şey JBOD değil RAID-0 veya daha yüksek gibi, düzeni. (örn. macOS'un zincirlenmiş takas dosyaları şeması , Linux swapon, vb.) Takas cihazları RAID'de olduğu gibi birbirine bağımlı olmaktan bağımsız olduğu için, kapsamlı bir kontrol toplamına gerek duymayız çünkü takas cihazını değiştirmek, diğer bağımlı takas cihazlarına bakmayı gerektirmez. yeni cihaza gitmesi gereken veriler. ZFS terimleriyle, takas cihazlarını diğer depolama cihazlarındaki yedek kopyalardan ayırmıyoruz.

Tüm bunlar, güvenilir bir takas cihazı kullanmanız gerektiği anlamına gelir. Bir keresinde, rahatsız edici bir ZFS havuzunu kurtarmak için 20 dolarlık bir harici USB HDD muhafazası kullandım, sadece muhafazanın kendisinin güvenilir olmadığını ve kendi hatalarını sürece soktuğunu keşfettim. ZFS'nin güçlü sağlama toplamı beni burada kurtardı. Bir takas dosyası ile depolama ortamının bu tür süvari muamelesi ile kaçamazsınız. Takas cihazı ölüyorsa ve bu nedenle aktarılan her 125 MiB'de tespit edilemeyen bir hata enjekte edebileceği en kötü duruma yaklaşıyorsa, en kısa sürede değiştirmeniz gerekir.

Bu sorudaki genel paranoya duygusu Bizans generalleri sorununun bir örneğidir . Bunu okuyun, 1982 tarihini, sorunu bilgisayar bilim dünyasına açıklayan akademik makalede düşünün ve 2019'da bu soruna eklemek için yeni düşüncelerin olup olmadığına karar verin. Ve eğer değilse, belki de Bizans Generalleri Sorunu hakkında bilen otuz yıllık CS mezunları tarafından tasarlanan teknolojiyi kullanacaksınız .

Burası çok başarılı bir yer. Muhtemelen bilgisayar bilimi dergilerinde ölümle tartışılmamış bir fikir, itiraz veya çözüm bulamazsınız.

SATA kesinlikle tamamen güvenilir değildir, ancak akademiye veya çekirdek geliştirme takımlarından birine katılmayacaksanız, burada en son teknolojiye maddi olarak katkıda bulunacak bir konumda olmayacaksınız. Bu sorunlar zaten elinizin altında, daha önce de belirttiğiniz gibi: ZFS, btrfs, ReFS ... Bir işletim sistemi kullanıcısı olarak, işletim sisteminin yaratıcılarının sizin için bu sorunları hallettiğine güvenmeniz gerekir, çünkü aynı zamanda Bizans Generali hakkında.

Öyle anda pratik değil ZFS ya Btrfs üstünde takas dosyası koymak için, ancak yukarıda size güvence etmezse, en azından xfs veya ext4 tepesinde koyabilirsiniz. Bu, özel bir takas bölümü kullanmaktan daha iyi olurdu.


1
RAID'iniz varsa , takasınızı RAID'in üstünde ideal şekilde çalıştırırsınız. Aksi takdirde, takasınız öldüğünde takas edilen programları kilitlersiniz. RAID'in kullanımlarından biri, bir disk arızasından kurtulmak, yeni bir diski çalışırken değiştirilebilir ve yeniden başlatmadan çalışmaya devam etmektir.
sourcejedi

2

dm-bütünlük

Bkz. Belgeler / aygıt eşleyici / dm-integrity.txt

dm-integritynormalde günlük tutma modunda kullanılır. Takas durumunda, dergi yayınlamadan bunu yapabilirsiniz. Bu, performans yükünü önemli ölçüde düşürebilir. Temiz olmayan bir kapatma sonrasında hataları yakalamak için her önyüklemede takas-bütünlük bölümünü yeniden biçimlendirmeniz gerekip gerekmediğinden emin değilim.

Gelen ilk olarak duyurulduğudm-integrity , yazar yerine "yüksek düzeyde veri bütünlüğü koruma" için bir tercih belirtiyor. Takas durumunda, bu sağlama toplamlarını RAM'de saklama olasılığını açar. Ancak, bu seçenek hem geçerli takas kodunda önemsiz değişiklikler yapılmasını hem de bellek kullanımını artırmayı gerektirir. (Geçerli kod, tek tek sayfaları / sektörleri değil, uzantıları kullanarak verimli bir şekilde değiştirir).


DIF / DIX?

DIX desteği Oracle tarafından Linux 2.6.27 (2008) ' de eklenmiştir .

DIX kullanımı uçtan uca bütünlük sağlıyor mu?

Satıcınıza danışabilirsiniz. Bu konuda yalan söyleyip söylemediklerini nasıl anlayacağınızı bilmiyorum.

DIX, işletim sistemi (işletim sistemi) ve HBA arasında uçuş halindeki verileri korumak için gereklidir .

DIF tek başına HBA ile depolama cihazı arasındaki uçuş verileri için korumayı arttırır . (Ayrıca bakınız: hata oranlarındaki fark hakkında bazı rakamlarla sunum ).

Tam olarak koruma alanındaki sağlama toplamı standart olduğu için, beklemedeki veriler için herhangi bir koruma sağlamadan DIX komutlarını uygulamak teknik olarak mümkündür . HBA'nın (veya depolama aygıtının) sağlama toplamını okuma zamanında yeniden oluşturmasını sağlayın. Bu görünüm orijinal DIX projesi ile oldukça açık bir şekilde ortaya konmuştur.

  • DIF / DIX, mantıksal blok sağlama toplamlarına diktir
    • Seni hala seviyoruz, btrfs!
    • Mantıksal blok sağlama toplamı hataları, bozuk verilerin algılanması için kullanılır
    • Algılama READ zamanında gerçekleşir
    • ... aylar sonra olabilecek orijinal tampon kaybedildi
    • Orijinal arabellek bozuksa gereksiz kopyalar da kötü olabilir
  • DIF / DIX proaktif olarak yolsuzluğu önlemekle ilgilidir
    • Kötü verilerin ilk etapta diskte depolanmasını önleme
    • ... ve orijinal tampon bellekten silinmeden önce problemleri bulmak

- ods.oracle.com adresinden lpc08-data-integrity.pdf

DIX hakkındaki ilk kayıtlarından biri, sürücü DIF'yi desteklemese bile OS ve HBA arasında DIX kullanma olasılığından bahsediyor.

DIX'in halihazırda kullanıldığı "kurumsal" bağlamlarda tam bir uyuşmazlık nispeten düşüktür; insanlar bunu fark ederdi. Ayrıca DIF, 520 bayt sektörlerle biçimlendirilebilen mevcut donanıma dayandırıldı. İddiaya göre DIF kullanma protokolü, öncelikle sürücüyü yeniden biçimlendirmenizi gerektirir, örn sg_format.

Daha muhtemel olan, gerçek uçtan uca prensibine uymayan bir uygulamadır . Bir örnek vermek gerekirse, DIX'in CPU döngülerini kaydetmesi için daha zayıf bir sağlama toplamı seçeneğini destekleyen bir satıcıdan bahsedilir; Bu yararlıdır, ancak uçtan uca tam bir koruma değildir.

Alternatif olarak, bir işletim sistemi kendi sağlama toplamlarını oluşturabilir ve bunları uygulama etiketi alanında saklayabilir. Bununla birlikte , mevcut Linux'ta (v4.20) bu konuda destek yoktur . 2014 yılında yazılan yorum, bunun "çok az depolama cihazının uygulama etiketi alanının kullanılmasına gerçekten izin vermesi" olabileceğini gösteriyor. (Bunun depolama aygıtının kendisine, HBA'ya veya her ikisine de atıfta bulunduğundan emin değilim).

Linux ile çalışan ne tür DIX cihazları mevcuttur?

Veri ve bütünlük meta veri arabelleklerinin ayrılması ve sağlama toplamlarında seçim, Veri Bütünlüğü Uzantıları [DIX] olarak adlandırılır. Bu uzantılar protokol gövdelerinin (T10, T13) kapsamı dışında olduğundan, Oracle ve ortakları bunları Depolama Ağı Endüstrisi Birliği içinde standartlaştırmaya çalışmaktadır.

- v4.20 / Dokümantasyon / blok / veri bütünlüğü.txt

Wikipedia bana DIF'nin NVMe 1.2.1'de standartlaştırıldığını söylüyor. SCSI HBA'lar için, işaret edecek bir standardımız yoksa bunu tespit etmek biraz zor görünüyor. Şu anda "Linux DIX" desteği :-) hakkında konuşmak en doğru olabilir. Kullanılabilir cihazlar var:

SCSI T10 DIF / DIX [sic] donanım satıcısının kalifiye olması ve belirli HBA ve depolama dizisi yapılandırması için tam destek sağlaması koşuluyla Red Hat Enterprise Linux 7.4'te tam olarak desteklenir. DIF / DIX diğer yapılandırmalarda desteklenmez, önyükleme aygıtında kullanılması desteklenmez ve sanallaştırılmış konuklarda desteklenmez.

Şu anda, aşağıdaki sağlayıcıların bu desteği sağladığı bilinmektedir ...

- RHEL 7.5 Sürüm Notları, Bölüm 16. Depolama

RHEL 7.5 sürüm notlarında belirtilen tüm donanım Fiber Kanal'dır.

Bu pazarı bilmiyorum. DIX, gelecekte sunucularda daha yaygın olarak kullanılabilir hale gelebilir. Tüketici SATA diskleri için neden kullanılabilir olmasının herhangi bir nedeni bilmiyorum - bildiğim kadarıyla komut formatı için fiili bir standart bile yok. NVMe'de daha yaygın olup olmadığını görmek isteyeceğim.


Teşekkürler! Dev-mapper için bütünlük "addon" hakkında bir şeyler duyduğumu sanıyordum, ama gerçekten emin değildim.
poige

2

Takas mı ??? <--- bu benim sorum

Değiştirme, Linux'ta hala korunmamaktadır (ancak UPD'ye bakın).

Tabii ki, Linux'ta takas deposu olabilen ZFS var, ancak bazı durumlarda hala bir kilitlenme var - bu seçeneği etkili bir şekilde iptal ediyor.

Btrfs hala takas dosyalarını işleyemez . Performansın düşük olduğu belirtilmekle birlikte geri dönüşün olası kullanımından bahsediyorlar. Linux 5'in sonunda alabileceğine dair bir belirti var (?)…

Geleneksel takasın kendisini sağlama toplamı ile koruyan yamalar onu ana akım haline getirmedi.

Yani, hepsi bir arada: hayır. Linux'un hala bir boşluğu var.

UPD. : Şöyle @ sourcejedi noktaları üzerinden dm-bütünlüğü gibi bir araç bulunmaktadır. Sürüm 4.12'den bu yana Linux çekirdeği, herhangi bir genel blok cihazına sağlama toplamı sağlamak için kullanılabilecek ve takas için kullanılanlar için aygıt eşleştiricisinin hedefine ulaştı. Takım, büyük dağıtımlara geniş ölçüde dahil edilmemiştir ve çoğunun udev alt sisteminde herhangi bir desteği yoktur, ancak sonunda bu değişmelidir. Bir yedekleme sağlayıcısıyla eşleştirildiğinde, örneğin Linux Yazılım RAID'in MD'sinin üstüne koyun, sadece bit çürümesini tespit etmek değil, aynı zamanda G / Ç isteğini sağlıklı verilere yeniden yönlendirmek de mümkün olmalıdır, çünkü dm bütünlüğü bir sorunu ve MD halletmek gerekir.


0

Ben "kanonik" bir yol olduğunu düşünmüyorum, bu yüzden aşağıdaki benim kişisel görüşüm.

Btrf'lerin ilerlemesini potansiyel bir kullanıcının bakış açısından izledikten sonra, bunun hala bir şekilde bana belirsiz olduğunu söylemeliyim. Olgun ve üretime hazır özellikler var ve görünüşte olgunlaşmamış ve kullanımı tehlikeli olan özellikler var.

Şahsen, hangi özelliğin kullanılacağına ve hangisinin kullanılamayacağına karar vermek için vaktim yok, bu özellikleri nasıl kapatacağımı veya açacağımı anlamaya ihtiyacım olan zamanı bırakalım.

Buna karşılık, ZFS kaya gibi sağlam ve olgun (IMHO). Yani, sorunuzu cevaplamak için ZFS'yi kullanırım (bu arada, çok fazla bellek tüketmez - aşağıya bakın).

Ancak sizin için, zaten kullandığınız için btrfs doğru seçim olabilir (sizi doğru anladıysam) ve yukarıdaki yorumlardan biri takas için nasıl kullanılacağını gösterir.

Şans eseri, son günlerde, her defasında kök dosya sistemi ve takas dahil olmak üzere bazı Linux sunucularını ZFS'ye koydum. Bunu yapmadan önce, birkaç gün süren çok ayrıntılı bir araştırma yaptım. Öğrendiklerimin kısa bir özeti:

ZFS'nin bellek tüketimi

ZFS'nin bellek tüketimi ile ilgili yaygın bir yanlış anlama var. ZFS genellikle gelmez değil fazla bellek tüketir; aslında, 2 GB RAM'e sahip makinelerde TB depolama alanı ile çalışır. Yalnızca tekilleştirme (varsayılan olarak kapalı) kullanırsanız, çok fazla RAM gerekir.

Donanım hatası algılama / düzeltme

SATA'lar, PATA'lar, RAID'ler veya diğer hata tespit / düzeltme mekanizmalarının veri bütünlüğü için yeterli olup olmadığı, ağ üzerindeki her yerde sonsuz tartışmalara ve hatta alev savaşlarına neden olan bir konudur. Teorik olarak, bir donanım depolama cihazı karşılaştığı herhangi bir hatayı rapor etmeli (ve muhtemelen düzeltmelidir) ve her seviyedeki veri iletim donanımı (yonga seti, bellek vb.) Da yapmalıdır.

Her durumda değiller ya da hatalara aşırı tepki veriyorlar. Örnek olarak, tipik bir RAID5 yapılandırması yapalım. Normal olarak, bir diskte sorun varsa, bunu diğer disklerden okunacak verileri yapılandıran ve geçiren RAID'e bildirir, ancak aynı zamanda hatalı diske geri yazar (bu da muhtemelen verileri yazmadan önce sektör); aynı disk çok fazla hata bildirirse, RAID diski çevrimdışına alır ve yöneticiyi bilgilendirir (düzgün yapılandırılmışsa).

Şimdiye kadar çok iyi, ancak disk hata bildirmeden hatalı verilerin bir diskten çıktığı durumlar var (bir sonraki bölüme bakın). Çoğu RAID, parite bilgisini kullanarak bu durumu tespit edebilir, ancak tepkileri aptalca: Hatayı bildirmek ve verilerin aktarılmasını durdurmak yerine, sadece hatalı verilere dayanarak pariteyi yeniden hesaplayacak ve yeni pariteyi ilgili Böylece hatalı verileri sonsuza dek doğru olarak işaretler.

Bu makul bir davranış mı? Bildiğim kadarıyla, çoğu donanım RAID5 denetleyicisi ve hatta Linux'un md RAID'i bu şekilde çalışıyor.

Btrfs hata düzeltme hakkında bilmiyorum, ama sonunda dokümanlar bir kez daha dikkatlice okumak gerekir, özellikle btrfs RAID kullanıyorsanız.

Sessiz bit çürümesi

Tüm alev savaşlarına ve (sahte) bilimsel tartışmalara rağmen: Gerçeklik çoğunlukla teoriden farklıdır ve teori bunun tersini belirtmesine rağmen sessiz bit çürümesi kesinlikle gerçekleşir (sessiz bot çürüğü genellikle depolama aygıtındaki bir veri, Bu veri okunduğunda hata veriyor, ancak bu tanıma giden iletim yolunun herhangi bir yerine çevirme bitleri ekleyeceğim).

Bu benim kişisel görüşüm değil: En azından Google, Amazon ve CERN tam olarak bu konuyu kapsayan ayrıntılı beyaz makaleler yayınladılar. Bildiriler ücretsiz olarak halka açık olarak indirilebilir. Birkaç milyon sabit disk ve yüzbinlerce sunucu / depolama aygıtı ile sistematik denemeler yaptılar, çünkü tespit edilmemiş veri bozulmalarıyla ilgili problemleri olduğu ya da gerçekleşmeden önce bunu önlemek için ne yapacaklarını bilmek istedikleri için.

Özetle, sunucu çiftliklerindeki veriler MTBF istatistiklerinden veya diğer teorilerden beklenenden daha yüksek bir oranda bozulmuştu. Önemli ölçüde daha yüksek olarak, büyüklük derecelerini kastediyorum.

Bu yüzden sessiz bit çürümesi, yani iletim yolunun herhangi bir noktasında tespit edilmemiş veri bozulması gerçek bir yaşam sorunudur.

Veri ömrü

Warren Young, takas verilerinin ömrünün kısa olduğunu söylediğinde doğrudur. Ancak aşağıdaki düşünceyi eklemek istiyorum: Yalnızca veri (belgeler anlamında) takas edilmez , aynı zamanda O / S'nin bazı kısımlarını veya çalışan diğer yazılımları değiştirir . Takasta bir MP3 varsa, saygısız bir bit ile yaşayabilirdim. (Aşırı bir durum nedeniyle) benim üretim httpd sunucu yazılımı parçaları takas ise, ben hiçbir şekilde daha sonra fark edilmezse bozuk kod yürütülmesine yol açan bir saygısız bit ile yaşayamaz.

son söz

Benim için ZFS bu sorunları çözüyor ya da daha doğrusu onları disklerden belleğe taşıyor ve böylece bazı büyüklüklerde sessiz bit çürümesi olasılığını azaltıyor . Ayrıca, düzgün yapılandırılırsa (yani RAID yerine aynalar), beklendiği gibi çalışan ve sonuçta kolayca anlaşılabilen temiz ve makul bir hata düzeltmesi sağlar.

Bunu söyledikten sonra, kesinlikle mutlak güvenlik elde edemeyeceğinizi lütfen unutmayın. Şahsen, ECC RAM'ime disklerimden daha fazla güveniyorum ve uçtan uca kontrol toplamı ile ZFS'nin büyüklük dereceleriyle sorun olasılığını azalttığına inanıyorum. Ben istiyorum asla rağmen, ECC RAM olmadan ZFS'yi kullanılması önerilir.

Feragatname: Hiçbir şekilde herhangi bir ZFS satıcısı veya geliştiricisi ile ilişkili değilim. Bu, ZFS'nin tüm varyantları (çatalları) için geçerlidir. Geçtiğimiz günlerde hayranı oldum ...

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.