Невдалий мій жорсткий диск?

Я просто спробував запустити тест на своєму hdd, і він не хоче пройти самотест. Ось результат:

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

Отже, цей диск вийшов з ладу?

Ваш привід дуже радий зробити самотест; з підсумків, за минулу годину було зроблено більше п'яти з них. І всі вони провалилися, на початку тесту, з помилками читання.

Так, цей жорсткий диск виходить з ладу. Як зазначається у відомому звіті Google Labs (хоча наразі я не можу покласти руку на посилання на нього), якщо smartctlсказано, що ваш накопичувач не працює, це, мабуть, є (перефразую).

Редагувати : не намагайтеся зберегти його. Зніміть усі дані та замініть їх.

Щоб відповісти на ваше запитання, невдалий тест SMART є надійною ознакою неминучої несправності накопичувача. Ви повинні створити резервну копію даних та замінити накопичувач якомога швидше, щоб запобігти можливій втраті даних.

@ sj0h згадав кількість циклів завантаження, яка дуже висока в 447 630. (Більшість сучасних жорстких дисків розроблені, щоб витримати 600 000 циклів навантаження / розвантаження.) Зазвичай це спричинено функцією Advanced Power Management (APM), яка намагається заощадити енергію, стоячи на головках (вивантажуючи їх з тарілок) через кілька секунд простоювати Голови завантажуються назад на блюдо, коли це необхідно. У більшості систем, де жорсткі диски отримують переривчасту активність увімкнення та вимкнення, це може спричинити багато циклів завантаження / вивантаження. Щоб вимкнути APM, запустіть таку команду в кореневому рядку:

smartctl -s apm,off /dev/sda

Цю команду потрібно буде запускати щоразу, коли система перемикається в режим живлення або переводиться у режим сну, або привід інакше вимикається, оскільки цей параметр не зберігається при відключенні диска.

На мій досвід, це різко зменшить кількість циклів навантаження / розвантаження, а отже, ймовірність того, що ви знову відчуєте подібний збій у майбутньому. Однак зауважте, що це збільшує споживання енергії та температуру приводу. Якщо привід постійно працює при температурі понад 50 ° C, ризик передчасного виходу з ладу збільшується, тому ви можете залишити APM увімкнутим (або увімкнути його, якщо він вимкнений) у теплі місяці.

Окрім помилок читання, врахуйте також кількість циклів завантаження. При майже 500 000 це може означати причину несправності або принаймні високого зносу циклу навантаження. Існує цикл навантаження на кожну хвилину часу включення живлення. Після заміни накопичувача переконайтеся, що новий диск теж не робить цього.

Так, у вас 16 секторів нечитабельно, ви намагалися зробити кілька тестів, які не вдалися приблизно в одній і тій же області накопичувача, так що резервне копіювання швидко, але майте на увазі, що у вас є дані, недоступні вже зараз, затримуючись поблизу сектори 92290592, 92290596.

У вас можуть бути інші проблемні області, ви все ще не знаєте, чи ці 16 секторів є послідовними чи розповсюдженими, якщо ви хочете грати після резервного копіювання, ви можете зробити селективний самотест з -t select, startlba-endlba.

Current_Pending_Sector означає, що прошивка жорсткого диска намагалася його прочитати, але не може, вона спробує в кілька разів більше (коли операційна система вимагає цього), поки не вийде з ладу і не позначить її як Offline_Uncorrectable або замінить пошкоджений сектор іншим запасним сектором, якщо ОС записує на нього (тим самим збільшуючи Reallocated_Sector_Ct при цьому).

Я б особисто замінив привід. Якщо ви з якихось причин цього ще не хочете робити, але ще затримаєтесь з диском, вам потрібен певний спосіб переконатися, що ви не використовуєте шкідливі області для нових файлів.

У мене був такий привід на старий Mac, який просто записував відео, і вирішив, що ще не хочу його змінювати, оскільки відео просто було приємно мати. Тому мені потрібно було ізолювати помилки. Спершу я створив порожню папку лише для поганих файлів, а потім спробував прочитати всі наявні файли на диску, і будь-який з тих, хто має помилку в, переміщено до каталогу bad-files (сподіваюся, лише неважливо).

Тоді я створив безліч унікально названих файлів одного мегабайт для заповнення жорсткого диска (тому весь порожній простір знаходився зараз в одному з цих файлів 1 Мб), а потім повторив процедуру. Усі файли з помилками в них були переміщені в каталог з поганими файлами, а ті, що залишилися, були хорошими і могли бути видалені, щоб відновити поганий пробіл.

Тепер ви можете використовувати привід трохи довше, але не використовувати його для важливих речей. Він більше вийде з ладу і, швидше за все, буде незручно, коли це станеться.

Це не дуже хороший знак. Ви повинні переконатися, що вміст диска є резервним копієм, а не використовувати його для нічого важливого.

Однак я бачив диски з невдалими секторами, які перерозподілили їх і залишалися функціонуючими протягом багатьох років, тому ви могли тримати їх деякий час, наприклад, для неважливих матеріалів або додаткових резервних копій.

Одне, що слід зробити, було б побачити, які файли були пошкоджені нечитабельними секторами, і записати в ці сектори, щоб змусити перерозподіл диска (переміщення їх з "Current_Pending_Sector" в "Reallocated_Sector_Ct"). Якщо ви використовуєте Linux, див. Http://smartmontools.sourceforge.net/badblockhowto.html . Після перерозподілу секторів самоперевірка повинна або пройти, або повідомити про більш нечитабельні сектори.

Я не згоден з більшістю відповідей в тому, що я не думаю, що погані сектори обов'язково є ознакою неминучої невдачі. Як говорить http://blog.mmueh.net/index.php/2010/12/09/luks-meets-badblocks/ , "кожен жорсткий привід починає створювати погані сектори в якийсь момент свого життя".