Плохой сектор указывает на сбой диска?


16

Моя система Ubuntu 13.10 работала очень плохо в течение последнего дня или около того. Глядя на журналы ядра, выясняется, что у старого SATA-диска объемом 3 года проблемы с конкретным сектором:

Nov  4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov  4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65
Nov  4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT
Nov  4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 tag 0 dma 4096 in
Nov  4 20:54:04 mediaserver kernel: [10893.039202]          res 51/40:00:f8:3f:83/40:00:af:00:00/10 Emask 0x9 (media error)
Nov  4 20:54:04 mediaserver kernel: [10893.039207] ata4.01: status: { DRDY ERR }
Nov  4 20:54:04 mediaserver kernel: [10893.039211] ata4.01: error: { UNC }
Nov  4 20:54:04 mediaserver kernel: [10893.148527] ata4.00: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180322] ata4.01: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180345] sd 3:0:1:0: [sdc] Unhandled sense code
Nov  4 20:54:04 mediaserver kernel: [10893.180349] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180353] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  4 20:54:04 mediaserver kernel: [10893.180356] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180359] Sense Key : Medium Error [current] [descriptor]
Nov  4 20:54:04 mediaserver kernel: [10893.180371] Descriptor sense data with sense descriptors (in hex):
Nov  4 20:54:04 mediaserver kernel: [10893.180373]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180384]         af 83 3f f8
Nov  4 20:54:04 mediaserver kernel: [10893.180389] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180393] Add. Sense: Unrecovered read error - auto reallocate failed
Nov  4 20:54:04 mediaserver kernel: [10893.180396] sd 3:0:1:0: [sdc] CDB:
Nov  4 20:54:04 mediaserver kernel: [10893.180398] Read(16): 88 00 00 00 00 00 af 83 3f f8 00 00 00 08 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180412] end_request: I/O error, dev sdc, sector 2944614392
Nov  4 20:54:04 mediaserver kernel: [10893.180431] ata4: EH complete

kern.logФайл вокруг 33MB основном полон ошибок выше неоднократных и сектор не появляется будет отличаться в неоднократных сообщениях.

В настоящее время я запускаю следующую команду на теперь не подключенном диске, чтобы проверить и попытаться разобраться в любых проблемах, которые могут возникнуть на диске. Я около 12 часов и ожидаю, что это займет еще 24/48 часов, поскольку диск такой большой:

e2fsck -c -c -p -v /dev/sdc1

Мой вопрос: этот диск не работает, или я смотрю на общую проблему здесь? Мне интересно, есть ли какой-то смысл для меня исправлять или игнорировать поврежденные сектора и должен ли я заменить диск по гарантии, пока он все еще покрыт. Мне немного не хватает знаний о приведенной выше команде, поэтому я скептически отношусь к тому, поможет ли это или нет.

Быстрое обновление!

Через 2 дня e2fsck наконец-то закончил со множеством «многократно заявленных блоков в inode». Попытка смонтировать файловую систему привела к ошибке, заставив ее вернуться в режим только для чтения:

Nov 11 08:29:05 mediaserver kernel: [211822.287758] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Nov 11 08:29:05 mediaserver kernel: [211822.301699] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

Попытка прочитать сектор вручную:

sudo dd count=1 if=/dev/sdc of=/dev/null skip=2944614392
dd: reading ‘/dev/sdc’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.73077 s, 0.0 kB/s

Попытка написать ему:

sudo dd count=1 if=/dev/zero of=/dev/sdc seek=2944614392
dd: writing to ‘/dev/sdc’: Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 2.87869 s, 0.0 kB/s

По обоим пунктам Reallocated_Sector_Ctосталось 0.

Привод действительно часто входит в состояние сна. Я сейчас думаю, что это может быть проблема файловой системы? Я не на 100%.


4
Это почти / наверняка / знак, чтобы убедиться, что ваши резервные копии в порядке, а затем проверить ваше оборудование.
Шадур

Хм. Они немного устарели, но они там, независимо. Очень расстраивает, так как этот диск заменил другой неисправный.
MrNorm

Диски не удается, увидеть эти Q &, где я описал , как поступить: unix.stackexchange.com/search?q=user%3A7453+hdat
ОДС

2
... Если этот диск заменил неисправный, есть вероятность, что это контроллер, а не диск.
Шадур

Ответы:


17

Плохие сектора всегда указывают на сбой жесткого диска, фактически в тот момент, когда вы видите такую ​​ошибку ввода / вывода, вы, вероятно, уже потеряли / повредили некоторые данные. Сделайте резервную копию, если у вас ее еще нет, запустите самопроверку smartctl -t long /dev/diskи проверьте данные SMART smartctl -a /dev/disk. Получить замену, если можете.

Плохие сектора не могут быть восстановлены, их можно заменить только резервными секторами, что снижает производительность жесткого диска, поскольку они требуют дополнительных поисков для резервных секторов при каждом обращении к ним. Помещение таких секторов как плохих на уровне файловой системы помогает, поскольку к ним никогда не будет доступа; однако трудно определить, какие секторы уже были перераспределены диском, поэтому есть вероятность, что файловая система не узнает, чтобы избежать уязвимой области.


Благодарю. Действительно полезно знать, потому что это всегда было серой областью для меня. Я собираюсь обнулить диск и отправить его обратно, так как это в пределах гарантии.
MrNorm

1
Не так. Плохие сектора просто указывают на чрезвычайно высокий трафик в сектор. В большинстве случаев это указывает на сбой диска. Вы можете настроить скорость поиска, чтобы помечать медленные ответы как плохие, хотя ... Это слишком сложно, чтобы сказать всегда, хотя.
RobotHumans

2
Также ошибки чтения могут быть замечены для файловой системы, которая по некоторым причинам больше, чем фактический диск.
Торбьерн Равн Андерсен

@frostschutz в чем смысл Get a replacement if you can.? ты имеешь ввиду заменить диск?
самолет

10

Чтобы заставить перераспределить секторы, обычно нужно что-то записать в них. Однако, dd( D ISK D estroyer) не всегда работает, и очень небезопасно: если вы смешиваете skipи seekварианты, вы можете легко снимать себя в ноге, skipпинг в Nпервые блоках /dev/zeroи запись блока от этого «смещения» над сектор 0 вашего жесткого диска .

Если вы действительно знаете, что хотите заставить сектор перезаписываться нулями, вы должны использовать hdparm:

% sudo hdparm --read-sector 833192656 /dev/sda
/dev/sda:
reading sector 833192656: FAILED: Input/output error

Да, сектор 833192656 также не прошел смарт-тестирование. Чтобы записать в него нули, используйте --write-sector:

% sudo hdparm --write-sector 833192656 /dev/sda
/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media.
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

В качестве гарантии hdparmне пишите ничего, если вы не передадите --yes-i-know-what-i-am-doingпереключатель hdparm:

% sudo hdparm --yes-i-know-what-i-am-doing --write-sector 833192656 /dev/sda
/dev/sda:
re-writing sector 833192656: succeeded
% sudo hdparm --read-sector 833192656 /dev/sda                              

/dev/sda:
reading sector 833192656: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
[      ... more zeroes here...        ]
0000 0000 0000 0000 0000 0000 0000 0000

%

Хотя это древний ответ, мне действительно интересно, что вы подразумеваете под "дд не всегда работает". Вы предполагаете, что он может не записать данные в соответствии с инструкциями? Он не делает ничего особенно подверженного сбоям, просто копирует данные. Вы можете получить тот же результат, используя две строки практически на любом языке программирования.
TooTea

7

Нет, плохие сектора не всегда являются признаком неисправного диска. Иногда, если запись выполняется во время сбоя питания, данные в секторе будут повреждены, что приведет к ошибке при попытке прочитать их. Попытка записать новые данные в сектор может работать очень хорошо, так как в этом нет ничего физического.

Вы можете запустить badblocks -nна диске чтение и перезаписать каждый сектор, или в вашем случае, поскольку вы уже знаете номер рассматриваемого сектора, вы можете использовать ddдля записи на него нулей. Вы можете проверить статистику SMART с smartctl -a. Вы должны увидеть ожидающий перераспределенный счетчик, указывающий, сколько секторов не удалось прочитать, и после попытки записи сектора этот счетчик уменьшится. Число перераспределенных секторов может возрасти, и в этом случае он был физически неисправен и был переназначен в резервный пул, и это может быть признаком того, что диск вышел из строя. Если нет, то тогда это было просто взломано и должно быть хорошо сейчас.

Попробуйте сначала прочитать сектор:

dd count=1 if=/dev/sda of=/dev/null skip=nnnn

Если это не удастся, то у вас есть правильное число, тогда вы можете обнулить его с помощью:

dd count=1 if=/dev/zero of=/dev/sda seek=nnnn

Дважды проверьте, что вы набрали команду, прежде чем нажать Enter.


Интересно, ты так говоришь, потому что я получил интересную информацию после твоих команд. Я исправил свой вопрос выше.
MrNorm

По какой-то причине ваш привод не поддерживает SMART или почему вы еще этого не проверили?
frostschutz

1
@frostschutz "По обоим подсчетам Reallocated_Sector_Ct осталось 0." Кажется , что ОП уже проверил SMART.
CVn

@ MrNorm, пожалуйста, добавьте полный smartctl -aвывод на ваш вопрос.
Псуси

2
Пожалуйста, не используйте это (это даже не всегда работает), и если вы перепутаете пропустить и искать, вы перезапишете свою MBR. Смотрите мой ответ
Антти Хаапала
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.