Какова гранулярность URE жесткого диска (неисправимая ошибка чтения)?


8

tl; dr в случае появления URE на жестком диске, я потеряю 1 бит, 1 байт или размер сектора (512 байт или 4096 байт AF)? и если можно объяснить, почему так?

Справочная информация: здесь возникает вопрос, когда жесткий диск имеет проблемы с чтением данных. Конечно, диск может полностью потерпеть неудачу, оставив все свои данные потерянными (DISK FAIL), но случай, о котором я здесь спрашиваю, заключается в том, что при потере только меньшей его части (URE, неисправимая ошибка чтения).

Хотя я искал информацию о URE, я мало что знал. Это может быть вызвано тем, что то, что происходит внутри накопителя, то есть то, что скрыто от прямого взаимодействия с пользователем, такого как ECC-коррекция, для меня трудно связать с тем, что я получаю как пользователь - с секторами.

Представим, что у жесткого диска проблемы с чтением данных.

В этой ситуации, безусловно, это должно означать, что:

  • (a) некоторые биты сектора не могут быть прочитаны, или
  • (b) все биты могут быть прочитаны, но они не проходят проверку контрольной суммы (конечно, ожидающая проблема сектор 4096 байт - это не просто 8 * 4096 бит, но некоторые дополнительные биты / байт для проверки / исправления ошибок (т.е. биты четности) ) (с) ????

Я не верю в то, что когда мы находимся в ситуации, в которой произошла комбинация (a) и (b) и надежное восстановление байтов сектора 4096 не может быть выполнено, то чрезмерно полагать, что все они обязательно являются garpage на самом деле, если бы мы знали о внутренней логике исправления ошибок жесткого диска, мы могли бы вместо этого сказать: «посмотрите, что-то не получается, и с хорошим изменением по крайней мере 1,2,3, n бит / байт данных блока является« неправильным » ». Если бы мы излишне сохраняли байтовые строки ASCII «привет, привет ....., привет» в этом секторе, у нас на самом деле все еще может быть правдоподобная последовательность «привет, привет ....», прежде чем будет «... Uellohello ... "(то есть" e "->" U ").

Так какова гранулярность URE?

ОБНОВЛЕНИЕ: был комментарий, вводящий идею плохого сектора (и предполагающий, что это отражает гранулярность события URE. Это не абсурдно, предлагать это и, возможно, может быть использовано при ответе на вопрос. Все же я просто прочитал другой связанный вопрос об ожидающих нечитаемых секторах (здесь /unix/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sectors ), который заставляет меня думать, что в некоторых В сценариях действительно существует более размытая линия между потерянными данными в случае URE.


Обычно это десятки тысяч блоков, поврежденных одновременно в случае разбитой головы. Если это пыль и т. Д. Доступ к ближайшим блокам может нанести ущерб. Так что его редко так просто, как часть большей площади, можно реконструировать.
Джеймс Райан

@JamesRyan хорошая подсказка, всегда может быть хуже. Может быть, я просто спрашивал о наименьшем возможном случае (то есть только о потере сектора или, как это было частично решено в хороших ответах, части данных по секторам, в зависимости от типа внутри него). возможно, необходимо будет узнать больше о происхождении нечитаемых ошибок (и их стойкости, т.е. случайном гниении битов по сравнению с ударом головы). Но мы хотим ответить на вопросы здесь, чтобы я больше не усложнял этот вопрос
человечество и

Ответы:


8

Код исправления ошибок на жестком диске - это дополнительный фрагмент данных, связанный с каждым сектором оборудования. Во время записи прошивка привода рассчитывает эти данные и записывает их вместе с данными пользователя. Во время чтения прошивки считывает ECC вместе с данными и проверяет их вместе.

Для традиционного жесткого диска аппаратный сектор составляет 512 байт. Для диска расширенного формата это 4 КБ (не имеет значения, представляет ли диск 512-байтовые или 4 КБ сектора на интерфейсе, то есть 512e против 4kn).

Результат проверки после чтения имеет в основном три возможных результата:

  • сектор был прочитан без ошибок. Это на самом деле не совсем распространено на современных жестких дисках; битовые плотности таковы, что они зависят от работы ECC.

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

  • сектор был прочитан, но было слишком много «неправильных битов»; ошибки не могут быть исправлены.

В последнем случае накопитель обычно не возвращает никакого содержимого; он просто возвращает статус, указывающий на ошибку. Это потому, что невозможно узнать, какие биты являются подозрительными, не говоря уже о том, какими должны быть их значения. Поэтому весь сектор (биты ECC и все) является ненадежным. Невозможно определить, какая часть плохого сектора плохая, не говоря уже о том, каким должно быть его содержание. ECC - это "гештальт", который рассчитывается по всему контенту сектора, и если он не совпадает, то не совпадает весь сектор.

SpinRite работает, просто пытаясь прочитать поврежденный сектор снова и снова, используя функцию «технического обслуживания», которая возвращает данные (но без битов ECC), даже если накопитель сообщает «неисправимая ошибка». Как сказано в описании, связанном с DavidPostill, он может преуспеть с безошибочным (на самом деле «корректируемым», скорее всего) чтением; или он может быть способен вывести, по существу, путем усреднения возвращаемых битов разумное предположение о содержании сектора. У него больше нет возможности точно исправлять ошибки с помощью ECC, чем у привода; это математически невозможно.


Все еще математически невозможно, если данные внутри полезной нагрузки 4096 байт сами по себе являются комбинацией полезной нагрузки 4000 байт и еще одного 96-байтного ECC сверху? (например, потому что я был готов пожертвовать способностью к восстановлению в макете хранилища данных?).
человечествоANDpeace

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

1
Конечно. В этот момент это просто еще один ненадежный канал, но если в нем достаточно избыточности ... Суть в том, что стандартные драйверы ОС не будут выдавать содержимое сектора вообще, если накопитель считает, что ошибки неисправимы. RAID-5 и аналогичные схемы контроля четности делают то же самое на «внешнем уровне», а не внутри полей данных существующих секторов.
Джейми Ханрахан

Проблема в том, что драйверы os возвращают (по запросу) все, даже непроверенные данные, - это проблема, поскольку пользователь, не являющийся пользователем Windows, спросил об этом конкретно unix.stackexchange.com/questions/228254/…
humanityANDpeace

3

Какова гранулярность URE?

Неустранимые ошибки чтения (URE) - это ошибки чтения сектора. Если сектор не может быть прочитан без ошибок, не имеет значения, был ли это всего 1 байт или все байты сектора.

Зернистость - это размер сектора .

Даже если произошел сбой только 1 байта, вы обычно не получите никаких данных из этого сектора без использования специализированного программного обеспечения.


Можно ли восстановить данные из неисправного сектора?

SpinRite говорит:

SpinRite даже способен восстанавливать большую часть данных в секторе, который никогда не может быть идеально прочитан и который любая другая утилита полностью удаляет.

Посмотрите, как SpinRite восстанавливает нечитаемые данные .


Отказ от ответственности.

Я никоим образом не связан со SpinRite и никогда им не пользовался.


1
Я склонен думать, что это хороший ответ, не потому, что я обязательно согласен с тем, что в случае URE необходимо полностью потерять сектор (то есть после 4k данных), а потому, что жесткий диск может отбросить даже эту долю «плохой сектор», который все равно будет иметь значение. Представление аргументов SpinWrite подтверждает эту идею, поэтому ответ также дает более глубокое понимание.
человечествоANDpeace

2

Нет такой вещи, как «не могу прочитать немного», если только у вас нет действительно серьезной аппаратной ошибки, например, из-за того, что головка не может найти правильный путь, или если след сервомотора поврежден и не найден правильный сектор , Очевидно, что в любом случае у вас будет, по крайней мере, целый нечитаемый сектор.

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

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


1

Посмотрев на это и вдохновившись ответом https://superuser.com/a/969917/160771 от https://superuser.com/users/337631/davidpostill

Я хотел бы ответить представить несколько расширяющий альтернативный ответ. Во-первых, верно, что жесткий диск и его прошивка являются источником события URE, то есть события, когда данные не могут быть прочитаны. Кроме того, верно, что данные записываются на диск в секторах по 512 или 4096 байт используемых данных и около 50 или соответствующих 100 байт дополнительных данных, которые должны позволять проверку и исправление ошибок.

Поэтому говорить о URE естественно в контексте сектора жесткого диска. Термин « плохой сектор» , безусловно, несколько связан, но не идентичен ситуации, когда у нас есть сектор URE.

Сектор с некоторыми проблемами, которые нужно прочитать без ошибок, не обязательно является полностью бессмысленным. Возможно, что все 4096 данных были повреждены, но также может быть и то, что только на 1 бит больше, чем было исправимо надежно (через избыточные данные ECC, добавленные в каждый сектор), было повреждено.

В случае, в котором только несколько очень немногих байтов, которые больше, чем hdd был способен исправить, были повреждены, есть изменения, что часть из 4096 байтов все еще содержит значимые данные.

Примером может быть то, что 4096 представляет ASCII-символы в 2 предложениях. Тогда возможно, что одно или несколько предложений полностью не повреждены. Также возможно, что каждое 2-е или 3-е письмо было удалено. Если данные 4096 потеряны в событии URE, следовательно, до интерпретации и зависит от данных. Можно предположить, что у самих данных есть другой слой оболочки ECC, который позволит дальнейшее восстановление.

Поэтому хорошо, что большинство прошивок трактуют сектора URE иначе, чем плохие сектора:

Как правило, автоматическое переназначение секторов происходит только при записи в сектор. Логика этого заключается, по-видимому, в том, что даже если сектор не может быть прочитан нормально, он все равно может быть читаем с помощью методов восстановления данных. (из https://en.wikipedia.org/wiki/Bad_sector )

Или, если уж на то пошло, возможно, что часть сектора все еще содержит полезные данные.


Обратите внимание, что статья помечена как «нуждается во внимании эксперта», «возможно, содержит оригинальные исследования», а это конкретное утверждение помечено как «необходимо цитирование». То, как оно написано («предположительно» ??), также делает его очень похожим на то, что кто-то спекулирует, а не на то, что можно подтвердить высококачественным исходным материалом.
CVn
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.