Вопросы Теги

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

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

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

Как определить сектор и исправить этот ожидающий счет?

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

8
задан 1 October 2010 в 13:14

40 ответов

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

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

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

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

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

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

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

7
ответ дан 26 May 2018 в 01:14
  • 1
    Спасибо за подробный ответ. Эти три незавершенных сектора существовали в течение очень долгого времени, почти более 6 месяцев, вот почему я хотел исправить эти ожидающие сектора. И эти сектора находятся в моем основном / домашнем разделе, как я могу сделать это в Интернете? Вы упомянули размонтирование всех разделов, должен ли я сделать это из live cd? – Vish 2 October 2010 в 21:37
  • 2
    Поскольку это домашний раздел для вашей установки, вы бы действительно захотели выполнить вышеуказанные шаги из livecd. Убедитесь, что все разделы на диске размонтированы (включая замену разделов подкачки). – koushik 3 October 2010 в 07:59
  • 3
    Thats странно, у меня ожидающий счет в течение почти 6 месяцев с ext4, но когда я переустановил с помощью brtfs, он исчезнет. Поэтому я был обеспокоен. От вас совет, который я считал ожидающим пару недель, прежде чем что-то сделал. Теперь они внезапно исчезли! Поэтому я думаю, что ждать было лучше. :-) Считалось, что быстрее разрешить работу с btrfs. – Vish 11 October 2010 в 17:35

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

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

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

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

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

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

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

7
ответ дан 25 July 2018 в 23:09

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

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

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

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

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

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

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

7
ответ дан 27 July 2018 в 03:06

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

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

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

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

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

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

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

7
ответ дан 31 July 2018 в 11:07

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

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

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

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

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

  1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Disk Utility ( System - & gt; Administration - & gt; Disk Utility ). Если вы нажмете на имя диска в списке, отображаемом на левой панели, имя устройства можно прочитать с помощью «Устройство:» справа.
  2. Отключите все файловые системы на этом диске. Следующая команда не должна возвращать выходные данные. mount | grep -i & lt; имя устройства & gt;
  3. Выполнить следующую команду badblocks -sv -b 512 & lt; имя устройства & gt; Примечание. -b 512 состоит в том, чтобы выровнять блокировку до 512, чтобы вы могли использовать число, указанное этой командой, в качестве входа в dd , как описано в Форумы

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

7
ответ дан 2 August 2018 в 04:29

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

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

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

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

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

  1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Disk Utility ( System - & gt; Administration - & gt; Disk Utility ). Если вы нажмете на имя диска в списке, отображаемом на левой панели, имя устройства можно прочитать с помощью «Устройство:» справа.
  2. Отключите все файловые системы на этом диске. Следующая команда не должна возвращать выходные данные. mount | grep -i & lt; имя устройства & gt;
  3. Выполнить следующую команду badblocks -sv -b 512 & lt; имя устройства & gt; Примечание. -b 512 состоит в том, чтобы выровнять блокировку до 512, чтобы вы могли использовать число, указанное этой командой, в качестве входа в dd , как описано в Форумы

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

7
ответ дан 4 August 2018 в 21:02

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

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

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

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

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

  1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Disk Utility ( System - & gt; Administration - & gt; Disk Utility ). Если вы нажмете на имя диска в списке, отображаемом на левой панели, имя устройства можно прочитать с помощью «Устройство:» справа.
  2. Отключите все файловые системы на этом диске. Следующая команда не должна возвращать выходные данные. mount | grep -i & lt; имя устройства & gt;
  3. Выполнить следующую команду badblocks -sv -b 512 & lt; имя устройства & gt; Примечание. -b 512 состоит в том, чтобы выровнять блокировку до 512, чтобы вы могли использовать число, указанное этой командой, в качестве входа в dd , как описано в Форумы

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

7
ответ дан 6 August 2018 в 04:34

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

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

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

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

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

  1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Disk Utility ( System - & gt; Administration - & gt; Disk Utility ). Если вы нажмете на имя диска в списке, отображаемом на левой панели, имя устройства можно прочитать с помощью «Устройство:» справа.
  2. Отключите все файловые системы на этом диске. Следующая команда не должна возвращать выходные данные. mount | grep -i & lt; имя устройства & gt;
  3. Выполнить следующую команду badblocks -sv -b 512 & lt; имя устройства & gt; Примечание. -b 512 состоит в том, чтобы выровнять блокировку до 512, чтобы вы могли использовать число, указанное этой командой, в качестве входа в dd , как описано в Форумы

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

7
ответ дан 7 August 2018 в 22:43

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

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

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

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

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

  1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Disk Utility ( System - & gt; Administration - & gt; Disk Utility ). Если вы нажмете на имя диска в списке, отображаемом на левой панели, имя устройства можно прочитать с помощью «Устройство:» справа.
  2. Отключите все файловые системы на этом диске. Следующая команда не должна возвращать выходные данные. mount | grep -i & lt; имя устройства & gt;
  3. Выполнить следующую команду badblocks -sv -b 512 & lt; имя устройства & gt; Примечание. -b 512 состоит в том, чтобы выровнять блокировку до 512, чтобы вы могли использовать число, указанное этой командой, в качестве входа в dd , как описано в Форумы

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

7
ответ дан 10 August 2018 в 10:49

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

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

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

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

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

  1. Обратите внимание на файл устройства, соответствующий файловой системе. Это имеет вид / dev / hdc или / dev / sdb в зависимости от типа диска. Это отображается в Disk Utility ( System - & gt; Administration - & gt; Disk Utility ). Если вы нажмете на имя диска в списке, отображаемом на левой панели, имя устройства можно прочитать с помощью «Устройство:» справа.
  2. Отключите все файловые системы на этом диске. Следующая команда не должна возвращать выходные данные. mount | grep -i & lt; имя устройства & gt;
  3. Выполнить следующую команду badblocks -sv -b 512 & lt; имя устройства & gt; Примечание. -b 512 состоит в том, чтобы выровнять блокировку до 512, чтобы вы могли использовать число, указанное этой командой, в качестве входа в dd , как описано в Форумы

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

7
ответ дан 13 August 2018 в 17:23
  • 1
    Спасибо за подробный ответ. Эти три незавершенных сектора существовали в течение очень долгого времени, почти более 6 месяцев, вот почему я хотел исправить эти ожидающие сектора. И эти сектора находятся в моем основном / домашнем разделе, как я могу сделать это в Интернете? Вы упомянули размонтирование всех разделов, должен ли я сделать это из live cd? – Vish 2 October 2010 в 21:37
  • 2
    Поскольку это домашний раздел для вашей установки, вы бы действительно захотели выполнить вышеуказанные шаги из livecd. Убедитесь, что все разделы на диске размонтированы (включая замену разделов подкачки). – koushik 3 October 2010 в 07:59
  • 3
    Thats странно, у меня ожидающий счет в течение почти 6 месяцев с ext4, но когда я переустановил с помощью brtfs, он исчезнет. Поэтому я был обеспокоен. От вас совет, который я считал ожидающим пару недель, прежде чем что-то сделал. Теперь они внезапно исчезли! Поэтому я думаю, что ждать было лучше. :-) Считалось, что быстрее разрешить работу с btrfs. – Vish 11 October 2010 в 17:35

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

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

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

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

1
ответ дан 26 May 2018 в 01:14

Похоже, опция conv=noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 26 May 2018 в 01:14

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

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

1
ответ дан 26 May 2018 в 01:14

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

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

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

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

1
ответ дан 25 July 2018 в 23:09

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

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

1
ответ дан 25 July 2018 в 23:09

Похоже, опция conv=noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 25 July 2018 в 23:09

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

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

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

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

1
ответ дан 27 July 2018 в 03:06

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

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

1
ответ дан 27 July 2018 в 03:06

Похоже, опция conv=noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 27 July 2018 в 03:06

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

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

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

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

1
ответ дан 31 July 2018 в 11:07

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

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

1
ответ дан 31 July 2018 в 11:07

Похоже, опция conv=noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 31 July 2018 в 11:07

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

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

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

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

1
ответ дан 2 August 2018 в 04:29

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

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

1
ответ дан 2 August 2018 в 04:29

Похоже, опция conv = noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 2 August 2018 в 04:29

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

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

1
ответ дан 4 August 2018 в 21:02

Похоже, опция conv = noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 4 August 2018 в 21:02

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

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

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

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

1
ответ дан 4 August 2018 в 21:02

Похоже, опция conv = noerror помогает. Когда есть ошибка ввода-вывода, похоже, что этот параметр заставляет dd повторить попытку, пока он не завершит чтение / запись. Я создал исходный файл со следующей командой для каждого из плохих блоков, найденных командой badblocks (приведенной выше в Kaushik), и очистил «Текущий ожидающий секторный счет» («ожидание для переназначения») до нуля с 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
1
ответ дан 6 August 2018 в 04:34

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

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

1
ответ дан 6 August 2018 в 04:34

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

Похожие вопросы: