Bu smartctl (smartmon) verileri nasıl yorumlanır


20

3 yıldır yoğun kullanımda olan bir linux sunucumuz var. Üzerinde iyi davranmamış bir dizi sanallaştırılmış sunucu çalıştırıyoruz ve önemli bir süre boyunca sunucunun io kapasitesi aşıldı ve kötü iowait'e neden oldu. 3com akın denetleyicisine bağlı 4 500 gb Barracuda sata sürücüsü var. 1 Sürücünün işletim sistemi vardır ve diğer 3'ü kurulum baskını-5'tir.

Şimdi sürücülerin durumu ve bunların aktif olarak arızalanıp arızalanmadığı hakkında bir tartışmamız var.

İşte 4 diskten 1'inin çıkışının bir kısmı. Hepsinin nispeten benzer istatistikleri var:

SMART Öznitelikleri Veri Yapısı revizyon numarası: 10
Eşikli Satıcıya Özel SMART Öznitelikleri:
Kimlik No: ATTRIBUTE_NAME BAYRAK DEĞERİ ENERJİ TÜRÜ GÜNCELLEŞTİRİLDİ WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 118 099 006 Her Zaman Ön Başarısız - 169074425
  3 Spin_Up_Time 0x0003 095 092 000 Ön arıza Her zaman - 0
  4 Start_Stop_Count 0x0032 10010020 Eski_age Her Zaman - 26
  5 Relocated_Sector_Ct 0x0033 100100336 Ön arıza Her zaman - 0
  7 Seek_Error_Rate 0x000f 077 060 030 Her Zaman Ön Başarısız - 200009354607
  9 Power_On_Hours 0x0032 069 069000 Old_age Her Zaman - 27856
 10 Spin_Retry_Count 0x0013 100100917 Ön arıza Her zaman - 1
 12 Power_Cycle_Count 0x0032 10010020 Eski_age Daima - 26
184 Unknown_Attribute 0x0032 10010099 Eski_age Her Zaman - 0
187 Reported_Unrectrect 0x0032 100100000 Old_age Her Zaman - 0
188 Unknown_Attribute 0x0032 100100000 Old_age Her Zaman - 1
189 High_Fly_Writes 0x003a 100100000 Old_age Her Zaman - 0
190 Airflow_Temperature_Cel 0x0022 07106060 Eski_age Her Zaman - 29 (Ömür Boyu / Maks 26/37)
194 Sıcaklık_Celsius 0x0022 029040000 Eski_Her Zaman - 29 (0 21 0 0)
195 Hardware_ECC_Recovered 0x001a 046 033000 Eski_Her Zaman - 169074425
197 Current_Pending_Sector 0x0012 100100000 Old_age Her Zaman - 0
198 Offline_Uncorrectable 0x0010 100100000 Old_age Çevrimdışı - 0
199 UDMA_CRC_Error_Count 0x003e 200200000 Old_age Her Zaman - 0

SMART Hata Günlüğü Sürümü: 1
Hata Kaydedilmedi

Bunu benim yorumum, herhangi bir sürücünün aktif olarak başarısız olduğuna dair kötü sektörler veya başka göstergelerimiz olmadığıdır.

Ancak, yüksek Raw_Read_Error_Rate ve Seek_Error_Rate, sürücülerin ölmekte olduğunun göstergesi olarak gösteriliyor.


1
Burada iyi bir açıklama var (yeniden yayınlamak için çok uzun, lütfen bağlantıyı takip edin): lime-technology.com/wiki/Understanding_SMART_Reports Bağlantının kopması durumunda, bazı önemli alıntılar: "Bu, şu andaki hata oranının bir göstergesidir. düşük seviyeli fiziksel sektör okuma işlemleri. Normal işletimde DAİMA az sayıda hata vardır [...] sürücüde sorun yoktur. " ve "LÜTFEN RAW_VALUE numarasını tamamen görmezden gelin! Sadece Seagates ham değeri bildiriyor, bu evet değerini ham okuma hatalarının sayısı olarak görünüyor, ancak tamamen göz ardı edilmelidir."
Konrad Gajewski

Yanıtlar:


7

Deneyimlerime göre, Seagates'in bu iki SMART özelliği için garip sayıları var. Bir Seagate teşhisi koyarken, bunları görmezden gelmeye ve Yeniden Tahsis Edilen Sektör Sayısı gibi diğer alanlara daha yakından bakmaya eğilimliyim. Tabii ki, şüphe duyduğunuzda diski değiştirin, ancak yepyeni Seagates bile bu özellikler için yüksek sayılara sahip olacaktır.


58

Seagate diskleri için (ve muhtemelen WD'deki bazı eski diskler için) Seek_Error_Rate ve Raw_Read_Error_Rate, 48 bit sayıdır; burada en önemli 16 bit bir hata sayısıdır ve düşük 32 bit bir dizi işlemdir.

% python
>>> 200009354607 & 0xFFFFFFFF
2440858991
>>> (200009354607 & 0xFFFF00000000) >> 32
46

Bu nedenle diskiniz 46'sı başarısız olan 2440858991 aramalarını gerçekleştirdi. Seagate diskleriyle ilgili deneyimim, hata sayısı 1000'in üzerine çıktığında başarısız olma eğiliminde olmalarıdır. YMMV.


7
Bunun için teşekkürler, keşke asıl soruyu sorduğumda bu bilgiyi geri alsaydım.
gview

1
Bu çok faydalı. Beni panikten kurtardı.
Halsafar

Birisi bu ayırma ile 48 bit sayı olduğunu doğrulamak için herhangi bir bağlantı sağlayabilir mi? Bu sayıları onaylamak istiyorum
iuridiniz

9

"Arama hata oranı" ve "ham okuma hata oranı" RAW_VALUES, Seagate'in desteği dışında herkes için neredeyse anlamsızdır. Diğerlerinin belirttiği gibi, "yeniden tahsis edilen sektör sayısı" veya sürücünün hata günlüğündeki girdiler gibi parametrelerin ham değerlerinin daha yüksek bir arıza olasılığını göstermesi daha olasıdır.

Ancak, gösterge olarak okunması gereken VALUE, WORST ve THRESH sütunlarındaki yorumlanmış verilere göz atabilirsiniz:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH
  7 Seek_Error_Rate         0x000f   077   060   030

Yani arama hata oranınız şu anda "% 77 iyi" olarak kabul edilir ve "% 30 iyi" ulaştığında SMART tarafından bir sorun olarak rapor edilir. Bir zamanlar "% 60 iyi" kadar düşüktü, ama o zamandan beri sihirli bir şekilde iyileşti. Yorumlanan değerlerin dahili olarak sürücünün SMART mantığı tarafından hesaplandığını ve kesin hesaplamanın üretici tarafından yayınlanabileceğini veya yayınlanmayabileceğini ve genellikle kullanıcı tarafından ayarlanamayacağını unutmayın.

Şahsen ben, hata günlüğü girişleri içeren bir sürücüyü "başarısız" olarak görüyorum ve meydana gelir gelmez değiştirme talebinde bulunuyorum. Ama sonuçta, SMART verileri, Google tarafından yayınlanan bir araştırma makalesinin ortaya çıkardığı gibi, hata tahmini için oldukça zayıf bir gösterge olduğu ortaya çıktı.


4

Bu tartışmanın biraz eski olduğunu fark ettim ama 2 sentimi eklemek istiyorum. Akıllı bilgilerin, hata öncesi için oldukça iyi bir gösterge olduğunu gördüm. Akıllı bir eşik açıldığında sürücüyü değiştirin. Bu eşikler bunun içindir.

Zamanın büyük çoğunluğu kötü sektörleri görmeye başlayacaksınız. Bu, sürücünün arızalanmaya başladığına dair kesin bir işarettir. SMART beni birçok kez kurtardı. Yazılım RAID 1 kullanıyorum ve arızalı sürücüyü değiştirip diziyi yeniden oluşturduğunuz için çok yararlı.

Haftada bir de kısa ve uzun öz testler yapıyorum.

smartctl -t short /dev/sda
smartctl -t long /dev/sda 

Veya /etc/smartd.conf dosyasını ekleyin ve hatalar varsa size e-posta ile gönderin

/dev/sda -s L/../../3/22 -I 194 -m someemail@somedomain
/dev/sdb -s L/../../7/22 -I 194 -m someemail@somedomain

Günlük izlemeyi yüklediğinizden ve root'u bir e-posta adresine yönlendirdiğinizden ve günlük e-postaları günlük izinden kontrol ettiğinizden emin olun. SMARTD tetiklemeli bayraklar orada görünecek, ancak kimse bunu düzenli olarak izlemiyorsa hiçbir işe yaramaz.


1

Evet, bu alanlar kötü görünüyor ama smart'ın bildirdiği bilgiye artık güvenmiyorum (test makinem smartctrl ile veri okuduysanız uzun bir süre önce ölmesi gereken bir sürücüye sahip) Gerçek şu ki yüksek iowait ve sürücüler 3 yaşında. Bu, sürücüleri değiştirmeniz için yeterli olmalıdır.


1
Çeşitli nedenlerle donanıma yaptığımız yatırımı en üst düzeye çıkarmamız gerekiyor. Iyowait, kutuyu kurarken yaptığımız bazı yapılandırma hatalarının yanı sıra saçma yük ile de ilgiliydi.
gview

0

Bu yayında büyücülük yaptığım için üzgünüm, ancak tecrübelerime göre, Seagate diski için "Ham Okuma Hata Oranı" ve "Donanım ECC Kurtarıldı" alanları tam anlamıyla her yere gidecek ve sürekli olarak trilyonlar aralığına yükselecek İşleme devam etmek için sıfıra geri döner. İlk günden beri bu sorunu yaşayan ve oldukça birkaç yıl ve 3500+ saat kullanımdan sonra bile harika çalışan bir Seagate ST9750420AS var.

Durumunuzda bir alan çalıştırıyorsanız, bu alanlar güvenle göz ardı edilebilir. İki alanın aynı sayıyı ve sürekli olarak senkronize ettiğinden emin olun. Eğer değillerse ... iyi ... Bu aslında bir sorun anlamına gelebilir.


0

Bu yanıtın hesaplamalarını otomatikleştirmek için çevrimiçi javascript hesap makinesini kullanın:

https://yksi.ml/

Bu size şunları söyleyecektir:

  • Toplam işlem sayısı
  • Başarısız işlem sayısı

Hesap makinesi Seagate'ler için geçerlidir:

  • Hata Oranı Ara
  • Ham Okuma Hata Oranı
  • Donanım ECC Kurtarıldı

Normalleştirilmiş (0 ile 100 değerleri arasında) hesaplamayla ilgili daha fazla bilgi için bu makaleye bakın .

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.