Sabit Sürücülerdeki Veriler Hasarla İlgili Bir Uyarı Olmadan Bozulabilir mi?
Verilerimizi ve dosyalarımızı güvenli ve eksiksiz tutmak konusunda hepimiz endişeleniyoruz, ancak sorun hakkında herhangi bir bildirimde bulunmadan veya herhangi bir uyarı vermeden verilerin zarar görmesi ve bir kullanıcı tarafından erişilmesi mümkün mü? Bugünün Süper Kullanıcı Soru-Cevap yazısında endişeli bir okuyucunun sorusunun cevabı var.
Bugünün Soru ve Cevap oturumu bize topluluk tarafından yönlendirilen bir soru-cevap web sitesi grubu olan Stack Exchange'in bir alt birimi olan SuperUser'ın izniyle geliyor..
Fotoğraf genelleme izniyle (Flickr).
Soru
SuperUser okuyucu topo morto, sabit sürücülerdeki verinin hasara dair bir uyarı olmadan bozulabilir ve erişilip erişilemeyeceğini bilmek ister:
Bir sabit sürücünün fiziksel bozulmasının, işletim sistemi değişikliği fark etmeden ve dosyayı okurken kullanıcıya bildirmeden bitin bir dosyanın içeriğinde "dönmesine" neden olabilir mi? Örneğin, bir ASCII metin dosyasındaki bir “p” (ikili 01110000) bir “q” (ikili 01110001) olarak değişebilir mi, bir kullanıcı dosyayı açtığında, bir hata meydana geldiğinin farkında olmadan “q” görürler?
FAT, NTFS veya ReFS ile ilgili cevaplarla ilgileniyorum (eğer fark yaratırsa). İşletim sistemlerinin kullanıcıları bundan koruyacağını mı yoksa zaman içindeki kopyalar arasındaki değişimleri kontrol etmemiz gerekip gerekmediğini bilmek istiyorum..
Sabit sürücülerdeki veriler bozulabilir ve hasar konusunda bir uyarı olmadan erişilebilir?
Cevap
SuperUser yazarı Guntram Blohm'un cevabı bize:
Evet, bit çürüklüğü denilen bir şey var. Ancak hayır, fark edilmeden bir kullanıcıyı etkilemeyecek.
Bir sabit disk disklere bir sektör yazdığında, bitleri yalnızca RAM'de saklandıkları gibi yazmakla kalmaz, aynı bitin çok uzun süren dizileri olmadığından emin olmak için bir kodlama kullanır. Ayrıca, birkaç biti etkileyen hataları tamir etmesini ve birkaç biti daha fazla etkileyen hataları tespit etmesini sağlayan ECC kodları ekler..
Sabit sürücü sektörü okuduğunda, bu ECC kodlarını kontrol eder ve gerekirse verileri (ve mümkünse) onarır. Daha sonra olacaklar, sürücünün tanımlanmasından etkilenen durumlara ve sabit sürücünün donanım yazılımına bağlıdır..
- Bir sektör okunabiliyorsa ve ECC kodu sorunu yoksa, o zaman işletim sistemine aktarılır..
- Eğer bir sektör kolayca tamir edilebilirse, tamir edilen versiyon diske yazılabilir, okunabilir, daha sonra hatanın rastgele olup olmadığını (yani kozmik ışınlar vs.) veya medyada sistematik bir hata olup olmadığını belirlemek için doğrulanabilir..
- Sabit sürücü medyada bir hata olduğunu tespit ederse, sektörü yeniden tahsis eder.
- Bir sektör birkaç okuma denemesinden sonra okunamıyor veya düzeltilemiyorsa (RAID sabit sürücüsü olarak belirlenmiş bir sabit sürücüde), sabit sürücü vazgeçecek, sektörü yeniden tahsis edecek ve denetleyiciye bir sorun olduğunu söyleyecektir. . Sektörü diğer RAID üyelerinden yeniden yapılandırmak ve arızalı sabit sürücüye geri yazmak için RAID denetleyicisine güvenir ve bu da yeniden tahsis edilen sektörde saklar (umarım bir problemi yoktur).
- Bir sektör masaüstünün sabit sürücüsünde okunamıyor veya düzeltilemiyorsa, sabit sürücü daha fazla okuma girişiminde bulunacaktır. Sabit sürücünün kalitesine bağlı olarak, bu, kafanın yeniden konumlandırılmasını, tekrar tekrar okunduğunda döndürülen herhangi bir bit olup olmadığını kontrol etmeyi, hangi bitlerin en zayıf olduğunu kontrol etmeyi ve diğer bazı şeyleri içerebilir. Bu denemelerden herhangi biri başarılı olursa, sabit sürücü sektörü yeniden tahsis eder ve onarılan verileri geri yazar.
Bu, “masaüstü”, “NAS / RAID” veya “video izleme” sabit sürücüleri olarak satılan sabit sürücüler arasındaki ana farklardan biridir. Bir RAID sabit diski hızlı bir şekilde vazgeçebilir ve kullanıcının tarafında gecikmeyi önlemek için denetleyicinin sektörü onarmasını sağlayabilir. Bir masaüstü sabit diski tekrar tekrar denemeye devam edecektir, çünkü kullanıcının birkaç saniye beklemesini sağlamak, muhtemelen verilerin kaybedildiğini söylemekten daha iyidir. Ve bir video sabit diski sabit veri hızlarını hata kurtarmaya göre değerlendiriyor çünkü hasar görmüş bir çerçeve genellikle fark edilmeyecek.
Her halükarda, sabit sürücü bit çürüklüğü olup olmadığını bilecek, tipik olarak ondan kurtaracak ve eğer başaramazsa, kontrolöre hangi sürücüye işletim sistemini söyleyeceğini söyleyecektir. Ardından, hatayı kullanıcıya sunmak ve üzerinde hareket etmek işletim sistemine bağlıdır. Bu yüzden cybernard şöyle diyor:
- Hiçbir zaman tek bir hataya şahit olmadım, ancak tüm sektörlerin başarısız olduğu bir sürü sabit disk gördüm..
Sabit disk, bir sektörde bir sorun olup olmadığını bilecektir, ancak hangi bitlerin başarısız olduğunu bilmeyecektir. Başarısız olan tek bir bit daima ECC tarafından yakalanır..
Unutmayın ki chkdsk ve kendilerini otomatik olarak onarabilen dosya sistemleri, dosyalardaki verileri onarmaya yönelik değildir. Bunlar, bir dosyanın boyutunda, dizin girişi ile tahsis edilen blokların sayısı arasındaki fark gibi, dosya sisteminin yapısındaki bozulmayı hedefler. NTFS'in kendi kendini iyileştirme özelliği yapısal hasarı algılar ve verilerinizi daha fazla etkilemesini önler, ancak zaten zarar görmüş hiçbir veriyi onaramaz.
Elbette, verilerin zarar görmesinin başka nedenleri de vardır. Örneğin, bir denetleyicideki hatalı RAM, sabit sürücüye gönderilmeden önce verileri değiştirebilir. Bu durumda, sabit sürücüdeki hiçbir mekanizma verileri algılamayacak veya onaramayacaktır ve bu bir dosya sisteminin yapısının zarar görmesinin bir nedeni olabilir. Diğer nedenler arasında yazılım hataları, sabit sürücüye yazarken karartmalar (her ne kadar dosya sistemi günlüğü ile ele alınsa da) veya hatalı dosya sistemi sürücüleri (Linux'taki NTFS sürücüsü NTFS'nin tersine çevrildiğinden beri uzun süre salt okunur olarak ayarlandı. belgelenmedi ve geliştiriciler kendi kodlarına güvenmediler).
- Bir senaryoda, bir uygulamanın, her koşulda verilerin çalışır durumda bir kopyasını saklamak için iki farklı veri merkezinde bulunan iki dosyayı iki farklı sunucuya kaydedeceği bir senaryo vardı. Birkaç ay sonra, kopyalanan tüm dosyaların yaklaşık yüzde 0,1'inin, uygulamanın veritabanında depoladığı MD5 kontrol toplamıyla eşleşmediğini fark ettik. Sunucu ve SAN arasında hatalı bir fiber kablo olduğu ortaya çıktı.
Bu diğer nedenler, ZFS gibi bazı dosya sistemlerinin hataları saptamak için ek kontrol toplamı bilgileri tutmasının nedenidir. Sizi bir parça çürümekten daha yanlış giden bir çok şeyden korumak için tasarlanmıştır..
Açıklamaya eklemek için bir şey var mı? Yorumlarda ses kesiliyor. Diğer teknoloji meraklısı Stack Exchange kullanıcılarından daha fazla cevap okumak ister misiniz? Burada tüm tartışma konusuna göz atın.