Жесткий диск очень медленный, отказывает все больше и больше ошибок

Начиная с пары дней, мой 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 провел большое исследование по этому вопросу.

Другие вопросы по тегам