Sabit Diskim Başarısız mı?

Sadece hdd üzerinde bir test yapmaya çalıştım ve kendi kendine bir testi tamamlamak istemiyor. İşte sonuç:

smartctl --attributes --log=selftest /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-32-generic] (local build)

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       697
  3 Spin_Up_Time            0x0027   206   160   021    Pre-fail  Always       -       691
  4 Start_Stop_Count        0x0032   074   074   000    Old_age   Always       -       26734
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       28
  9 Power_On_Hours          0x0032   090   090   000    Old_age   Always       -       7432
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   097   097   000    Old_age   Always       -       3186
191 G-Sense_Error_Rate      0x0032   001   001   000    Old_age   Always       -       20473
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       84
193 Load_Cycle_Count        0x0032   051   051   000    Old_age   Always       -       447630
194 Temperature_Celsius     0x0022   113   099   000    Old_age   Always       -       34
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       16
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%      7432         92290592
# 2  Conveyance offline  Completed: read failure       90%      7432         92290596
# 3  Conveyance offline  Completed: read failure       90%      7432         92290592
# 4  Short offline       Completed: read failure       90%      7431         92290596
# 5  Extended offline    Completed: read failure       90%      7431         92290592

Peki bu disk bozuluyor mu?

Sürücünüz kendi kendini sınamak için çok mutlu; Özetten, son bir saat içinde bunların beşinden fazlasını yaptı. Ve hepsi testin başında, okuma hatalarıyla başarısız oldu.

Evet, bu sabit sürücü bozuluyor. Ünlü Google Labs raporunun dediği gibi (şu anda elimi bir linke sokamıyorum), smartctlsürücünüz arızalı diyorsa muhtemelen öyledir (Ben parola yapıyorum).

Düzenleme : kaydetmeye çalışmayın. Tüm verileri çıkarın ve değiştirin.

Sorunuzu yanıtlamak için, başarısız bir SMART testi, yakın bir sürücü arızasının kesin göstergesidir. Verilerinizi yedeklemeli ve olası veri kaybını önlemek için sürücüyü en kısa sürede değiştirmeniz gerekir.

sj0h, 447.630'da çok yüksek olan Yük Döngüsü Sayısından bahsetti. (Modern sabit sürücülerin çoğu, 600.000 yük / boşaltma döngüsüne dayanacak şekilde tasarlanmıştır.) Bu, genellikle birkaç saniye sonra kafaları park ederek (bunları plakalardan boşaltarak) gücü korumaya çalışan Gelişmiş Güç Yönetimi (APM) özelliğinden kaynaklanır. Boşta. Gerektiğinde kafalar tekrar plakalara yüklenir. Sabit sürücülerin aralıklı, açık ve kapalı etkinliklerine maruz kaldığı çoğu sistemde bu, çok fazla yükleme / boşaltma döngüsünün oluşmasına neden olabilir. APM'yi kapatmak için kök isteminde aşağıdaki komutu çalıştırın:

smartctl -s apm,off /dev/sda

Bu komut, sistem her kapatıldığında veya uyku moduna geçtiğinde veya sürücü kapatıldığında, sürücü kapatıldığında bu ayar korunmadığından çalıştırılmalıdır.

Tecrübelerime göre, bunu yapmak yükleme / boşaltma döngüsünün sayısını ve dolayısıyla gelecekte bu tür bir arızayı tekrar deneyimleme şansınızı önemli ölçüde azaltacaktır. Bununla birlikte, bunu yapmanın güç tüketimini ve sürüş sıcaklığını arttırdığını unutmayın. Sürücü sürekli 50 ° C'nin üzerindeki sıcaklıklarda çalışıyorsa, erken arıza riski artar, bu nedenle sıcak aylarda APM'yi açık bırakmak (veya kapalıysa açmak) isteyebilirsiniz.

Okuma hataları dışında, Yük Döngüsü Sayısını da dikkate alın. Neredeyse 500.000'de, bu bir başarısızlık sebebini veya en azından yüksek yük döngüsü aşınmasını gösterebilir. Her çalıştırma süresi için bir yük döngüsü vardır. Sürücüyü değiştirdikten sonra, yeni sürücünün de bunu yapmadığından emin olun.

Evet, okunamayan 16 sektörünüz var, sürücünün kabaca aynı alanında başarısız olan birkaç test yaptınız, bu nedenle hızlı bir şekilde yedekleyin, ancak şu anda yakınında kalarak erişilemeyen verileriniz olduğunu unutmayın. sektörler 92290592, 92290596.

Başka sorunlu alanlarınız olabilir, hala bu 16 sektörün ardışık mı yoksa yayılmış mı olduğunu bilmiyorsunuz, yedeklemeden sonra oynamak istiyorsanız -t select, startlba-endlba ile seçici bir kendi kendine sınama işlemi yapabilirsiniz.

Current_Pending_Sector, sabit disk belleniminin onu okumaya çalıştığı, ancak yapamadığı, birkaç kez daha deneyebileceği (işletim sistemi istediği zaman), başarısız olduğu ve Offline_Uncorrectable olarak işaretleyene kadar veya hasarlı sektörü başka bir yedek sektörün yerini alacağı anlamına gelir. İşletim sistemi buna yazıyor (böylece Reallocated_Sector_Ct arttırılıyor).

Şahsen sürücüyü değiştirirdim. Siz, bir nedenden ötürü henüz yapmak istemezseniz, ancak bir süre sonra sürücüyü kullanmaya devam ederseniz, yanlışlıkla hatalı dosyaları yeni dosyalar için kullanmamanız için bir yol gerekir.

Eski bir Mac’te böyle bir sürücü vardı ve sadece video kaydı yaptım ve videoların olması güzel olduğu için henüz değiştirmek istemediğime karar verdim. Bu yüzden hataları izole etmem gerekiyordu. İlk önce sadece kötü dosyalar için boş bir klasör yarattım ve daha sonra diskteki tüm dosyaları okumaya çalıştım ve içinde hata olanlardan biri bad-files dizinine taşındı (umarım sadece önemsiz).

Sonra sabit disk sürücüsünü doldurmak için benzersiz bir adla adlandırılmış bir megabayt dosya oluşturdum (bu nedenle tüm boş alan şimdi bu 1 MB dosyalardan birinde idi) ve işlemi tekrarladı. İçinde hatalı olan tüm dosyalar bad-files dizinine taşındı ve kalanlar iyiydi ve kötü alanı geri kazanmak için silinebiliyorlardı.

Artık sürücüyü biraz daha uzun süre kullanabilirsiniz, ancak önemli şeyler için kullanmayın. Daha fazla başarısız olacak ve bu gerçekleştiğinde büyük olasılıkla sakınca olacaktır.

Bu çok iyi bir işaret değil. Diskin içeriğinin yedeklendiğinden emin olmalı ve diski önemli bir şey için kullanmamalısınız.

Bununla birlikte, yeniden tahsis edilen ve yıllarca faaliyete geçen başarısız sektörleri olan diskler gördüm, bu nedenle bir süre için örneğin önemsiz şeyler veya ek yedeklemeler için saklayabilirsiniz.

O zaman yapılacak bir şey, hangi dosyaların okunamayan sektörler tarafından bozulduğunu görmek ve bu sektörlere disk tarafından yeniden tahsis edilmesini zorlamak için yazmaktır (bunları "Current_Pending_Sector" den "Reallocated_Sector_Ct" e ​​taşıyarak). Linux kullanıyorsanız, bkz. Http://smartmontools.sourceforge.net/badblockhowto.html . Sektörler yeniden tahsis edildikten sonra, kendi kendine test daha okunaksız sektörleri geçmeli veya raporlamalıdır.

Cevapların çoğuna katılmıyorum, çünkü kötü sektörlerin mutlaka yakın bir başarısızlık göstergesi olduğuna inanmıyorum . Gibi http://blog.mmueh.net/index.php/2010/12/09/luks-meets-badblocks/ diyor, "Her sabitdisk başlar ömrünün bir noktasında bozuk kesimleri üretmek için".