Жесткий диск очень медленный, отказывает все больше и больше ошибок
Начиная с пары дней, мой Seagate Momentus 7200.4 все больше и больше выходил из строя, возможно, из-за отключения электроэнергии. После "ПРЕДУПРЕЖДЕНИЕ: ваш жесткий диск выходит из строя" (я использую fedora), основным симптомом была медлительность: постоянное 100 % -ое ожидание ЦП в течение нескольких часов, практически невозможно что-либо сделать. Я сделал резервную копию, затем перезапустил и мне пришлось выполнить e2fsck -y (много выходных данных), который я должен был повторить позже (даже не загрузился в какой-то момент, паника ядра), я долго делал некоторые тесты 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.defaubxhhhh
Обновление: как вы сказали, диск должен быть уничтожен, я сделал dmesg | grep -oE "сектор.+$" | sort -u и я sudo hdparm --write-sector --yes-i-знаю-что-я-делаю 'да дюжина секторов. Теперь запустим еще один тест, посмотрим, что из этого получится.
Обновление 2: мне пришлось исправлять еще несколько плохих секторов с помощью hdparm вручную, но ночью позже все ошибки, которые я нахожу в системном журнале, похоже, были успешно исправлены автоматически, как обычно. В то же время я столкнулся с некоторыми забавными ошибками, такими как искаженный звук в стиле техно-музыки и сумасшедший grep, но для их исправления может быть достаточно yum-обновления. Последний smartctl -a /dev/sda выполнен без ошибок; Теперь у меня есть "Количество ошибок ATA: 5004", 2 для 197 Current_Pending_Sector и 198 Offline_Uncorrectable.
Обновление 3: система в основном работоспособна, но проблемы остаются: "Число ошибок ATA: 9484". Мне иногда приходится использовать трюк hdparm, но я думаю, что он не работает должным образом, потому что проблема позже появляется в следующем секторе. Offline_Unc корректируемый не растет, поэтому я подозреваю, что диск не может деактивировать поврежденные сектора. Я думаю, я должен сдаться и купить новый...
1 ответ
Надеюсь, все ваши данные будут заархивированы?
Если нет, получите новый диск как можно скорее, по крайней мере один такой же большой, как старый, и запустите локальное резервное копирование.
По моему опыту, гораздо проще заменить диск раньше, чем позже.
Однако, если у вас есть наличные деньги, вы можете инвестировать в копию Spinrite. Запустите это на диске - в крайних случаях это может занять несколько дней или даже недель. Он не всегда может восстановить диск, но делает это на удивление часто. Действительно, он будет регулярно возвращать диски с края, я уже воскресил пару ноутбуков. В одном случае он восстановил диск до точки, где он все еще используется более 12 месяцев спустя. В другом случае он восстановил большую часть данных, достаточную для того, чтобы сделать его более неторопливым. Это около 90 долларов США, хотя и не дешево. Если ошибки были вызваны отключением питания от вашей машины, Spinrite, вероятно, исправит ситуацию. Если нет, он покажет вам, насколько все плохо, и может дать вам достаточно времени, чтобы скопировать на другой диск.
Кстати, поврежденные секторы должны автоматически помечаться прошивкой на диске, с ними не стоит связываться. Интересно, что упражнение, которое Spinrite пропускает через диск, довольно часто сбрасывает поврежденные сектора, поскольку они могли быть отмечены из-за непоследовательного движения головки, а не из-за сбоя диска.
Кстати, как обнаружили многие исследователи, предупреждения SMART довольно бесполезны, поскольку они не являются хорошим предиктором сбоя диска. Google провел большое исследование по этому вопросу.