Sabit disk okuma hataları ... durur mu?

Hikayem oldukça basit bir şekilde başlıyor. Verilerinin çoğunu iki SATA sürücüsünden oluşan bir RAID-1'de depolayan Arch Linux çalıştıran hafif bir sunucum var. Yaklaşık 4 aydır sorunsuz çalışıyordu. Sonra aniden sürücülerden birinde okuma hataları almaya başladım. Her zaman, mesajlar şöyle görünüyordu:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Her hata farklı bir sektör numarasından şikayetçiydi ve diske erişen kullanıcı (ben) için birkaç saniyelik bir gecikmeye eşlik etti.

Smartctl çıkışını kontrol ettim ve aşağıdaki çıkışı gördüm (alakasız parçalar kırpılmış):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Günlüklere baktığımda, hataların aslında birkaç gün boyunca, çoğunlukla yedeklemeler sırasında değil, aynı zamanda çok hafif kullanım sırasında da (bir metin dosyasını kaydetmeye çalıştığım her 5. kez) gerçekleştiğini buldum. Diskimin öldüğünü, RAID-1'in uygun şekilde kullandığını ve yeni bir disk sipariş etmenin zamanı geldiğini düşündüm. Yeni bir disk sipariş ettim.

Şaşırtıcı bir şekilde, bir gün sonra hatalar ... durdu. Onları düzeltmek için hiçbir şey yapmamıştım. Yeniden başlatmadım, sürücüyü çevrimdışına almadım, hiçbir şey. Ancak hatalar durdu.

Bu noktada, şimdi kötü sektörlerin diskin boşta kalan kısımlarında olup olmadığını merak ederek, diski RAID'den çıkardım, RAID'e geri koydum ve ardından gelen tam yeniden senkronizasyonu tamamlamasına izin verdim. Yeniden senkronizasyon 9 saat sonra hatasız tamamlandı (2 TB diskler biraz zaman alır).

Ayrıca, smartctl çıkışı aşağıdaki gibi biraz değişti:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Yani, bunun beni tuhaflaştıran kısmı, elbette, "Ne zamandan beri kötü diskler kendilerini düzeltir?"

Sürücünün çok küçük bir alanının kendiliğinden kötüleşmesi ve sürücünün sektör yeniden tahsis kodu devreye girmeden önce sadece 3 gün (!) Almasının mümkün olduğunu ve bazı yedek sektörleri diskin kötü bir bölgesinde eşlediğini düşünüyorum ... Ama bunun olduğunu şimdiye kadar gördüğümü söyleyemem.

Başka kimse bu tür davranışlar gördü mü? Eğer öyleyse, sürüşten sonraki deneyiminiz neydi? Yine mi oldu? Disk sonunda tamamen başarısız oldu mu? Yoksa açıklanamayan sadece açıklanamayan bir aksaklık mıydı?

Benim durumumda, zaten yedek sürücüye sahibim (garanti kapsamında elde edildi), bu yüzden muhtemelen sürücüyü yine de değiştireceğim. Ama bunu bir şekilde yanlış teşhis edip etmediğimi bilmek isterim. Eğer yardımcı olursa, sorunun oluştuğu andan itibaren 'smartctl -a' çıktısı aldım. Sadece biraz uzun, bu yüzden buraya göndermedim.

Sürücü yüzeyinin belirli bir fiziksel bölgesi kötüleşirse, bu sektörler başarıyla eşleştirilinceye kadar, o alana yazılan verileri okumaya çalıştığınızda kurtarılamayan okuma hataları alırsınız. Sürücü, sektörlerin kötü olduğunu (sektörlere erişim başarısızlıklarından sonra) biliyor, ancak zaten veri bulunduğundan sektörleri yeniden eşleştiremiyor. Sürücüyü biçimlendirirseniz veya "bozuk" sektörlerin üzerine yazarsanız, sürücünün bozuk sektörleri eşleme fırsatı olur.

Kötü sektörler haritalandıktan sonra ve daha fazla sürücü yüzeyi arızalanmadığı sürece iyi durumdasınız demektir.

Ortam sürücüsünün bir bölümünün kötüleşmesi ile tekrar yayılması veya tekrarlanması arasında çok fazla korelasyon olup olmadığını bilmek için mevcut sürücülerin sürücü arıza modelleri hakkında yeterli bilgim yok. Eğer bir korelasyon yoksa, o zaman kötü sektörler haritaya çıkarılırsa, iyi durumdasınız demektir. Orada ise olan bir ilişki, o zaman bu sürücü için sonun başlangıcıdır.

Modern sürücülerin çoğu, kötüye giden bir bloğu "vektörler". Sürücünün yedek blok havuzu vardır ve ürün yazılımı, sürücünün kötü olduğu bilinen blokları değiştirmek için bunları kullanır. Sürücü, doğru veri sağlayamadığı için bir bloğu OKUYMADIĞINDA bu yeniden eşlemeyi yapamaz. Sadece "okuma hatası" döndürür. Bloğu kötü olarak MARK yapar, bu nedenle blok doğru bir şekilde okunursa blok vektör edilir ve yedek bloğa doğru veriler yazılır. İşletim sistemi hiç "beklemede olan vektör" durumunda olan bir bloğa YAZI yazarsa, blok vektörlenir ve veriler yedek bloğa yazılır.

Linux yazılım baskını, bir cihazdan bir okuma hatası alındığında, dizideki diğer elemanlardan doğru verileri alır ve daha sonra bozuk bloğu tekrar yazmaya çalışır. Yani, eğer yazma TAMAM çalışırsa, veri güvenlidir, eğer değilse, sürücü sadece yukarıdakileri yapar, bloğu vektörler ve sonra yazma işlemini gerçekleştirir. Yani, sürücü, baskın sisteminin yardımıyla sadece kendini onardı!

Bu tür olayların oldukça nadir olduğunu varsayarsak, muhtemelen devam etmek güvenlidir. Çok fazla yedek blok kullanılıyorsa, sürücüde bir sorun olabilir. Yedek bloklara kaç yedek bloğun vektör edilebileceğine dair bir sınırlama vardır ve bu sürücünün bir fonksiyonudur.

Evet, bunu da gördüm ve çok benzer koşullar altında. Benim durumumda, bu dublör beni çeken bir "tüketici sınıfı" Western Digital 1 TB "Yeşil" sürücü (WD10EARS) oldu. SMART Current_Pending_Sectorham değeri sıfırdan 6'ya ve sonra 8'e gitti ve SMART izleme arka plan programının bana bazı uğursuz e-postalar göndermesini istedi.

Ben mdadm --failed ve --removed sürücüden sürücü ve badblocksüzerinde yıkıcı olmayan bir geçiş koştu ve evet, görünüşe göre 2 düzineden fazla kötü blok vardı. Yeni sürücü yaklaşık bir gün sonra geldiğinde diziyi düzelttim ve hayat devam etti.

Kısa bir süre sonra, can sıkıcı bir sıkıntıdan, badblocks"başarısız" sürücüsünde yeniden kötüleşip kötüleşmediğini görmek için yeniden başladım . Aksine, sürücü tamamen "tamir etti": sıfır kötü blok! Başımı sallayarak onu sildim ve geri dönüştürülmek ya da bağışlanmak üzere ayırdım.

Ders: Her türlü tuhaflığa ve güvenilmezliğe katlanmaya istekli değilseniz, sunucularda tüketici sınıfı sürücüler kullanmayın. Sonuç: Sunucu bileşenlerinde ucuza çıkmayın, çünkü sonunda zaten ekstra zaman ve ağırlaştırmayla bunlar için ödeme yaparsınız.

Sunucu ortamlarında, bu hataları gösteren, sabit olan veya olmayan sürücüleri atmak yaygın bir uygulamadır. Sektörün sert hataları, ortama fiziksel yüzey hasarının bir işareti olabilir - ve bir yüzeyi çizerseniz, genellikle malzemeyi çiziklerin kenarlarına kaydırırsınız ve bu yüzeyin düzleminden daha yüksek bir çapak elde edersiniz - veya aşındırıcı toz (cam! ). Her ikisi de mükemmel bir şekilde pürüzsüz olduğu kabul edilen iki yüzey arasındaki çok ince bir hava yastığına dayanan mekanik bir sisteme oldukça zarar verme eğilimindedir ... bu nedenle belirli bir sayıya ulaştıklarında orta hatalar daha hızlı çoğalma eğilimindedir.