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

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

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

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

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

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

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

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

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

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

1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Дисковой утилите ( System -> Administration -> Disk Utility). Если щелкнуть имя диска в списке, отображаемом на левой панели, имя устройства можно прочесть напротив «Device:» справа.

2. Размонтируйте все файловые системы на этом диске. Следующая команда не должна возвращать ничего

   mount | grep -i <device-name>
   

3. Запустите следующую команду

   badblocks -sv -b 512 <device-name>
   

   Примечание . -b 512Выровняйте размер блока по 512, чтобы вы могли использовать число, сообщаемое этой командой, в качестве входных данных, ddкак описано в сообщении на форуме.

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

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

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

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

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

Похоже, 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

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

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