Soru Sabit disk okuma hataları… durur mu?


Hikayem oldukça basit bir şekilde başlıyor. İki adet SATA sürücüsünden oluşan bir RAID-1'deki verilerin çoğunu depolayan Arch Linux'u çalıştıran bir hafif sunucuya sahibim. Yaklaşık 4 ay boyunca sorunsuz çalışıyordu. Ardından, aniden sürücülerden birinde okuma hataları almaya başladım. Her zaman, mesajlar bunlara çok benziyordu:

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 bir hata, farklı bir sektör numarasından şikayet etti ve diske erişen kullanıcı (me) için birkaç saniyelik bir gecikme eşlik etti.

Smartctl çıkışını kontrol ettim ve aşağıdaki çıktıyı gördüm (ilgisiz 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, aynı zamanda çok hafif kullanımlarda (bir metin dosyasını kaydetmeye çalıştığım her 5 seferde) meydana geldiğini fark ettim. Diskimin ölmekte olduğu, RAID-1'in uygun şekilde işlediği ve yedek bir disk sipariş etme zamanı olduğu sonucuna vardım. Yeni bir disk sipariş ettim.

Sürprizimden çok, bir gün sonra, hatalar ... durdu. Onları düzeltmek için hiçbir şey yapmadım. Yeniden başlatılmadım, sürücüyü çevrimdışına almadım, hiçbir şey. Ancak hatalar durdu.

Bu noktada, bozuk sektörlerin şimdi diskin boş bölümlerinde olup olmadığını görmek için merak ettim, diski RAID'den çıkardım, RAID'e geri koydum ve bunun ardından gelen tam resync'i tamamlamasına izin verdim. Resync herhangi bir hata olmadan tamamlandı, 9 saat sonra (2TB diskler biraz zaman alıyor).

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

Öyleyse, bunun beni parçalayan kısmı, elbette, "Ne zamandan beri kötü diskler kendilerini tamir ediyor?"

Sürücünün çok küçük bir alanının kendiliğinden kötüleştiğini ve sürücünün sektörün yeniden tahsis kodu başlamadan önce 3 gün sürdüğünü ve diskin bozuk bir alanı üzerinde bazı yedek sektörleri haritaladığını düşünüyorum. Ama bunun olduğunu hiç görmediğimi söyleyemem.

Bu tür davranışlarda başka biri var mıydı? Eğer öyleyse, daha sonra sürücü ile deneyiminiz neydi? Yine mi oldu? Disk sonunda tamamen başarısız mıydı? Yoksa açıklanamayan açıklanamayan bir aksaklık mıydı?

Benim durumumda, zaten değiştirilen sürücüye sahibim (garanti kapsamında elde edilmiştir), bu yüzden muhtemelen sadece sürücüyü değiştireceğim. Ama bunu bir şekilde yanlış teşhis edip etmediğimi bilmek isterim. Eğer yardımcı olursa, problemin ne zaman gerçekleştiğinden tam olarak 'smartctl-a' çıktısını aldım. Sadece biraz uzun, bu yüzden buraya göndermedim.


10
2018-04-20 23:42


Menşei


Sürücünün markası ve modeli nedir? - Antonius Bloch
Western Digital Caviar Black 2TB sürücüsü, WD2001FAAS modeli. Tam olarak sunucu sınıfı bir disk değil, tam olarak bir veri merkezi üretim sınıfı sunucu değil. - Rick Koshi


Cevaplar:


Sürücü yüzeyinin belirli bir fiziksel bölgesi kötü giderse, o sektörler başarılı bir şekilde haritalanana kadar, o alana yazılan herhangi bir veriyi okumaya çalıştığınızda, okunamayan okuma hataları elde edersiniz. Sürücü, sektörlerin kötü olduğunu (sektörlere erişme başarısızlıklarından sonra) biliyor, ancak zaten veri tuttukları için sektörleri yeniden yapılandıramıyor. Sürücüyü biçimlendirirseniz veya "kötü" sektörlerin üzerine yazarsanız, sürücü kötü sektörleri haritalandırma olanağına sahip olur.

Bozuk kesimler haritalandığında ve sürücü yüzeyinin daha fazlası başarısız olduğu sürece, iyi durumdasınız demektir.

Güncel disklerin sürücü arızası modelleri hakkında, medya yüzeyinin bir kısmının kötüleşmesi ve tekrar yayılması ya da ortaya çıkması arasında çok fazla ilişki olup olmadığını bilmek için yeterli bilgim yok. Bir korelasyon yoksa, kötü sektörler haritalandırıldıktan sonra, iyi durumdasınız. Eğer varsa olduğu Bir korelasyon, o zaman bu, sürücünün sonunun başlangıcıdır.


9
2018-04-21 01:45





En modern sürücüler, kötü giden bir bloğu "dışarı" iterler. Sürücünün bir yedek blok havuzu vardır ve ürün yazılımı, sürücünün kötü olduğu bilinen tüm blokları değiştirmek için bunları kullanır. Sürücü, doğru verileri sağlayamadığı için bir bloğu OKUMADIĞINDA bu yeniden eşleştirmeyi yapamaz. Sadece "okuma hatası" verir. Bloğu kötü olarak işaretler, böylece blok doğru bir şekilde okunduğunda, blok vektörü çıkarılır ve doğru veri, yedek bloğa yazılır. Eğer işletim sistemi "beklemede vektör" durumunda olan bir bloğa YAZILIYORSA, bu durumda blok vektörü çıkarılır ve veriler yedek bloğa yazılır.

Linux yazılım baskısı, bir cihazdan okuma hatası aldığında, dizideki diğer öğelerden doğru verileri alır ve daha sonra kötü bloğu tekrar YAZMA yapmaya çalışır. Öyleyse, yazma işlemi tamamsa, veriler güvenlidir, eğer değilse, sürücü sadece yukarıdakileri yapar, bloğu vektörler ve daha sonra yazımı gerçekleştirir. SO, sürücü, baskının yardımıyla, kendini tamir etti!

Bu tür olayların makul derecede nadir olduğunu varsayarak, muhtemelen devam etmek güvenlidir. Çok fazla yedek blok kullanılıyorsa, sürücünün bir sorunu olabilir. Yedek bloklara kaç tane değiştirme bloğunun vektör edilebileceğine dair bir sınır vardır ve bu, sürücünün bir işlevidir.


4
2017-12-14 14:45





Evet, bunu da gördüm ve çok benzer koşullar altında. Benim durumumda, bu stunt beni çekti "tüketici dereceli" Western Digital 1TB "Yeşil" sürücü (WD10EARS) oldu. Akıllı Current_Pending_Sector Ham değer sıfırdan 6'ya ve daha sonra 8'e çıktı, SMART izleme daemon'unun bana bazı uğursuz e-postalar göndermesini istedi.

ben mdadm --failed ve --removed diziden sürücü ve tahribatsız bir geçiş koştu badblocks Üzerinde ve evet, görünüşte 2 düzine kötü bloklar vardı. Yedek sürücü bir gün sonra geldiğinde, diziyi tamir ettim ve hayat devam etti.

Bundan kısa bir süre sonra, can sıkıntısı yüzünden, ben yeniden badblocks kötüleşen olup olmadığını görmek için "başarısız" sürücüde. Tam tersine, sürücü kendini tamamen "tamir etti": sıfır hatalı bloklar! Kafamı salladım, sildim ve geri dönüştürülecek ya da bağışlanacak bir kenara koydum.

Ders: Her türlü gariplik ve güvenilmezliğe sahip olmaya istekli ve istekli olmadığınız sürece, tüketici sınıfı sürücüleri sunucularda kullanmayın. Sonuç: Sunucu bileşenlerinde ucuza çıkmayın çünkü sonuçta her zaman için para ödeyeceksiniz, ekstra zamanda ve ağırlaştırıyorsunuz.


3
2018-04-21 01:37



Bulunan kötü blokların hepsi başarılı bir şekilde haritalanmışsa ve ek sektörler kötü gitmediyse, sonuçlarınız görmeyi beklediğiniz sonuçlardır. Son paragrafın yine de doğru cevaptır. - Eddie


Sunucu ortamlarında, bu tür hataları düzeltilmiş veya sabit olan sürücüleri atmak yaygın bir uygulamadır. Sektördeki sert hatalar, ortama fiziksel yüzey hasarının bir işareti olabilir - ve eğer bir yüzeyi çizerseniz, genellikle ya malzemeyi çizmenin kenarlarına kaydırırsınız ve bu yüzeyin düzleminden daha yüksek bir çapak veya aşındırıcı toz (cam! ). Her ikisi de, mükemmel bir şekilde pürüzsüz olan iki yüzey arasında çok ince bir hava yastığına dayanan mekanik bir sisteme zarar vermektedir. Bu nedenle, belirli bir sayıya ulaşmaya başladıklarında orta hataların daha hızlı bir şekilde çoğalma eğilimi vardır.


0
2017-12-14 15:09