Как я могу исправить текущий ожидающий подсчет секторов

Question 1

Из SMART Data видно, что у меня есть 3 ожидающих подсчета секторов. (Запуск Ubuntu Maverick.)

Я пытался перейти по на форумы, чтобы узнать, как решить эту проблему , но я не могу определить точное число секторов для записи в этот сектор. Я запустил полный самотестирование из Дисковой утилиты, но Дисковая утилита не показывает точное число секторов в Maverick, хотя и не уверена в более ранних версиях. Изменилось ли это в Maverick?

Как определить сектор и зафиксировать этот счетчик? Является ли этот совет на форумах безопасным?

PS: у меня есть другие проблемы с «Перераспределенным подсчетом секторов», из того, что я гуглил, его не исправить. Есть ли способ предотвратить его рост?

Question 2

В худшем случае вы всегда можете сделать это: размонтировать диск или массив и остановить любой массив.

dd if=/dev/sdX of=/dev/sdX iflag=direct,sync oflag=direct,sync

Это займет много времени, но должно работать.

В идеале вы могли бы запросить список дефектов роста жесткого диска (glist), но я не понял, как это сделать.

Question 3

Question 4

Это на самом деле длинный комментарий; -)

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

Не могли бы вы заявить о большей цели, стоящей за этим? Помимо проблем с блоками, требующими переназначения, есть ли еще какие-то раздражения / проблемы, которые вы пытаетесь решить, делая это?

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

Но если вам нужно найти нарушающие блоки, вы можете использовать следующие шаги:

Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Дисковой утилите (System -> Administration -> Disk Utility). Если щелкнуть имя диска в списке, отображаемом на левой панели, имя устройства можно прочесть напротив «Device:» справа.
Размонтируйте все файловые системы на этом диске. Следующая команда не должна возвращать ничего.
```
mount | grep -i <device-name>
```
Выполните следующую команду
```
badblocks -sv -b 512 <device-name>
```
Примечание Параметр -b 512 предназначен для выравнивания размера блока до 512, чтобы вы могли использовать число, сообщаемое эту команду в качестве входных данных для dd, как описано в на форумах

Я бы не советовал все вышеперечисленное, так как в любом случае об этом заботится обычный диск операции.

Question 5

Когда оно превышает 0, это, как правило, признак неизбежного отказа привода. Я не верю, что это можно исправить без замены жесткого диска.

См. http://kb.acronis.com/content/9133?nocache=1

.

Question 6

Похоже, опция conv=noerror помогает. Когда возникает ошибка ввода / вывода, похоже, что эта опция заставляет dd повторить попытку до завершения чтения / записи. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (заданной Каусиком выше), и он очистил «Текущий счетчик ожидающих секторов» («ожидающий повторного отображения») с нуля с 5.

sudo dd bs=512 count=1 conv=noerror ibs=512 obs=512 if=/dev/sda of=/dev/sda iflag=direct,sync oflag=direct,sync skip=3186809 seek=3186809

Jorge Castro · Answer 1 · 1 October 2010 в 12:14