Пару дней назад мой Seagate Momentus 7200.4 все чаще и чаще выходил из строя, возможно, из-за отключения питания. После "WARNING: Your hard disk is failure" (я использую Fedora) основным симптомом была медлительность: постоянное 100% ожидание CPU в течение нескольких часов, практически невозможно что-либо сделать. Я сделал резервную копию, затем перезагрузил и мне пришлось сделать e2fsck -y (много вывода), который мне пришлось повторить позже (в какой-то момент он даже не загрузился, kernel panic), я провел несколько тестов smartctl, длинных и коротких, я оставил его в покое на ночь, чтобы он исправил сектор или что-то в этом роде.
Теперь количество накапливающихся ошибок, похоже, уменьшилось, и компьютер в основном пригоден для использования, но что мне делать: есть ли какая-то команда fsck с лучшим эффектом или какой-то другой способ заставить его пропускать плохие сектора и продолжать работать, кроме как исправлять сектора по одному с помощью hdparm? Или диск обязательно нужно выбросить?
Выдержки из smartctl -x /dev/sda :
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate POSR-- 085 074 006 - 243348742
5 Reallocated_Sector_Ct PO--CK 100 100 036 - 0
7 Seek_Error_Rate POSR-- 084 060 030 - 238612361
9 Power_On_Hours -O--CK 087 087 000 - 11535
198 Offline_Uncorrectable ----C- 100 100 000 - 8
199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0
240 Head_Flying_Hours ------ 100 253 000 - 132680129719553
241 Total_LBAs_Written ------ 100 253 000 - 2525013242
242 Total_LBAs_Read ------ 100 253 000 - 2162196433
Error 3759 [18] occurred at disk power-on lifetime: 11535 hours (480 days + 15 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 00 00 22 7e 00 3d 2a 00 00 Error: UNC at LBA = 0x227e003d2a = 148142832938
Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 00 00 08 00 22 7e 00 3d 28 40 00 18:38:24.892 READ FPDMA QUEUED
27 00 00 00 00 00 00 00 00 00 00 e0 00 18:38:24.891 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 00 18:38:24.889 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 00 18:38:24.889 SET FEATURES [Set transfer mode]
27 00 00 00 00 00 00 00 00 00 00 e0 00 18:38:24.889 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
SMART Extended Self-test Log Version: 1 (1 sectors)
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 11528 574443398
Более: http://p.defau.lt/?DTSGCmr7mb_anDD3IQ9Bgg http://p.defau.lt/?hNM7_BusGyz4DYLi9XX0Kg http://p.defau.lt/?wQArANAXPLnpyD87xUY6CA http://p.defau.lt/?hXbtLh27yFZhySu0y9axJw
Обновлять: как вы сказали, диск уже должен быть выброшен, я сделал dmesg | grep -oE "sector.+$" | sort -u и sudo hdparm --write-sector --yes-i-know-what-i-am-doing 'da дюжину секторов. Теперь запускаю еще один тест, посмотрим, что из этого выйдет.
Обновление 2:Мне пришлось вручную исправить еще несколько поврежденных секторов с помощью hdparmно, спустя ночь, все ошибки, которые я нахожу в системном журнале, похоже, успешно автоматически исправились, как и должно быть. Тем временем я столкнулся с некоторыми забавными ошибками, такими как искаженный звук а-ля техно-музыка и сходящие с ума grep, но обновления yum, возможно, было достаточно, чтобы исправить их. Последний smartctl -a /dev/sda завершился без ошибок; теперь у меня "ATA Error Count: 5004", 2 для 197 Current_Pending_Sector и 198 Offline_Uncorrectable.
Обновление 3: система в основном пригодна к использованию, но проблемы остаются: "ATA Error Count: 9484". Иногда мне приходится использовать трюк с hdparm, но я думаю, что он работает неправильно, потому что проблема позже появляется в следующем секторе. Offline_Uncorrectable не растет, поэтому я подозреваю, что диск не может деактивировать плохие сектора. Думаю, мне придется сдаться и купить новый...
решение1
Надеюсь, все ваши данные сохранены?
Если нет, как можно скорее приобретите новый диск, по крайней мере такого же размера, как старый, и начните локальное резервное копирование.
По моему опыту, гораздо проще заменить диск раньше, чем позже.
Однако, если у вас есть деньги, вы можете вложиться в копиюСпинрит. Запустите его на диске — в крайних случаях это может занять несколько дней или даже недель. Он не всегда может восстановить диск, но делает это на удивление часто. Действительно, он регулярно возвращает диски с края пропасти, я уже восстанавливал с его помощью пару ноутбуков. В одном случае он восстановил диск до состояния, когда он все еще используется более 12 месяцев спустя. В другом случае он восстановил большую часть данных, достаточно, чтобы можно было выполнить более неторопливое восстановление. Это стоит около 90 долларов США, так что это недешево. Если ошибки были вызваны сбоем питания на вашем компьютере, Spinrite, вероятно, исправит все отлично. Если нет, он покажет вам, насколько все плохо, и может дать вам достаточно времени для копирования на другой диск.
Кстати, плохие сектора должны автоматически помечаться прошивкой на диске, вам не следует с ними возиться. Интересно, что упражнение, через которое Spinrite пропускает диск, довольно часто сбрасывает плохие сектора, поскольку они могли быть помечены из-за несогласованного движения головки, а не из-за отказа диска.
Кстати, как обнаружили многие исследователи, предупреждения SMART довольно бесполезны, поскольку они не являются хорошим предсказателем отказа диска. Google провел большое исследование по этому вопросу.