У чому полягає деталізація URE жорсткого диска (непоправна помилка читання)?

tl; dr, якщо URE трапляється на hdd, я втрачу 1bit, 1Byte або розмір сектора (512Bytes, або 4096 байт AF)? і, якщо можливо, поясніть, чому так?

Передумови: Тут виникає питання, коли на жорсткому диску є проблема з читанням даних. Безумовно, диск не може повністю залишити всі свої дані втраченими (DISK FAIL), але справа, про яку я про це розповідаю, полягає в тому, що коли втрачається лише менша її частина (URE, нерегульована помилка читання).

Незважаючи на те, що я шукав інформацію щодо URE, я напевно мало дізнався. Це може бути причиною того, що те, що відбувається всередині диска, тобто те, що приховано від прямої взаємодії з користувачем, як-от виправлення ECC, для мене важко пов'язати з тим, що я отримую доступ як користувач - секторами.

Уявімо собі, що hdd має проблеми з читанням даних.

У цій ситуації, безумовно, це має означати або що:

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

Я не вірю в те, що коли ми опинилися в ситуації, коли поєднання (a) і (b) сталося і надійне відновлення байтів сектору 4096 неможливо зробити, то надмірно вважати, що обов'язково всі вони є гардером насправді, якби нам було відомо про логіку виправлення помилок hdd, ми могли б замість цього сказати "дивіться, що щось не перевіряється, і при гарній зміні принаймні 1,2,3, n біт / байт даних блоку є" неправильним " ". Якби ми надмірно заощаджували "привіт, привіт ....., привіт" рядки байтів ASCII в цьому секторі, ми насправді все-таки можемо мати справедливу послідовність "привіт, привіт ....", перш ніж з'явиться "... Uellohello ... "(тобто" е "->" U ").

Так у чому полягає деталізація URE?

ОНОВЛЕННЯ: з'явився коментар, що вводив ідею поганого сектора (і припускає, що це відображає деталізацію події URE. Це не абсурдно, пропонувати це і, можливо, може бути використане для відповіді на питання. Але я просто прочитав ще одне пов'язане запитання про непрочитані сектори (тут /unix/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sectors ), що змушує мене думати, що в деяких У сценаріях дійсно є більш розмита лінія між даними, втраченими у разі URE.

Код виправлення помилок на жорсткому диску - це додатковий фрагмент даних, пов’язаний із кожним сектором обладнання. Під час запису прошивки накопичувача обчислюють ці дані та записують їх разом із даними користувача. Під час читання прошивки зчитують ECC разом із даними та разом їх перевіряють.

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

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

• сектор було прочитано без помилок. Це насправді не зовсім часто зустрічається на сучасних жорстких дисках; щільність бітів така, що залежить від роботи ECC.

• сектор був прочитаний з виправними помилками. Як зазначено вище, це не рідкість; очікується. Привід повертає дані користувачеві із застосуванням виправлення помилок.

• сектор був прочитаний, але було занадто багато "неправильних бітів"; помилки неможливо було виправити.

В останньому випадку привід зазвичай не повертає жодного вмісту; він просто повертає статус, що вказує на помилку. Це тому, що неможливо дізнатися, які біти підозрювані, не кажучи вже про те, якими мають бути їх значення. Тому весь сектор (ECC біти та всі) є недостовірним. Неможливо визначити, яка частина поганого сектора є поганою, не кажучи вже про те, яким повинен бути її зміст. ECC - це "гештальт", який обчислюється по всьому вмісту сектору, і якщо він не відповідає, то весь сектор не відповідає.

SpinRite працює, просто намагаючись читати поганий сектор знову і знову, використовуючи функцію "зчитування технічного обслуговування", яка повертає дані (але без бітів ECC), навіть незважаючи на те, що накопичувач каже "помилка, яка не може бути виправлена". Як сказано в описі, пов’язаному з DavidPostill, це може досягти успіху з помилкою помилки (насправді "коригувальна" скоріше) читається; або, можливо, вдасться вивести, по суті, шляхом усереднення повернених бітів разом, розумною здогадкою щодо вмісту сектора. Він не має більше можливостей точно виправляти помилки за допомогою ECC, ніж накопичувач; це математично неможливо.

У чому полягає деталізація URE?

Непоправні помилки читання (URE) - це помилки читання в секторі. Якщо сектор не можна прочитати без помилок, не має значення, був він лише 1 байт або всі байти сектора.

Детальність - це розмір сектора .

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

Чи можна відновити дані з невдалого сектора?

SpinRite каже:

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

Дивіться, як SpinRite відновлює нечитані дані .

Відмова від відповідальності.

Я жодним чином не пов’язаний зі SpinRite , і ніколи його не використовував.

Немає такого поняття, як "не вмію читати трохи", якщо у вас справді не буває серйозної апаратної помилки, наприклад, голова не в змозі домагатися правильної доріжки, або серводоріжка пошкоджена і не знайдено правильний сектор. . Очевидно, що в будь-якому випадку у вас був би принаймні цілий нечитабельний сектор.

В іншому випадку, ви завжди отримуєте біти назад, вони просто, можливо, неправильні біти. Тут надходить код для виправлення помилок; він додає деяку кількість зайвих бітів ECC до кожного сектору, так що будь-яка правильна комбінація бітів даних та ECC бітів дотримується певного алгебраїчного правила. Якщо всі біти були прочитані правильно, код буде підтверджений, і дані можуть бути передані безпосередньо назад. Якщо невелика кількість бітів було прочитано неправильно, код ECC можна використовувати, щоб визначити, які саме з них, і виправити їх, тому всі дані передаються правильно. Якщо більше число бітів читався неправильно, код ECC може виявити , що була помилка, але вона більше не має достатньої інформації , щоб з'ясувати , які біти невірні; це непоправна помилка читання. Якщодуже велика кількість бітів читається неправильно, тоді код може перевірити правильно «випадково», а привід поверне пошкоджені дані, але при достатній кількості ECC бітів ймовірність цього може бути зроблена настільки маленькою, скільки вам подобається.

Отже, щоб відповісти на питання, я думаю, що ви стикалися - якщо сталася часткова помилка читання, але було достатньо інформації, щоб зрозуміти, де сталася помилка, то її також можна виправити, і комп'ютер взагалі не побачить помилки . Це насправді відбувається постійно. Невиправлена ​​помилка трапляється, коли неможливо визначити, які біти даних є дійсними, а які - ні, і оскільки код для виправлення помилок обчислюється в секторі, це відбувається при деталізації сектора.

Поглянувши на це і надихнувшись відповіді https://superuser.com/a/969917/160771 з https://superuser.com/users/337631/davidpostill

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

Якщо говорити про URE, то, природно, це відбувається в умовах жорсткого диска. Термін поганий сектор , безумовно, дещо пов'язаний, але не тотожний ситуації, коли у нас є сектор URE.

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

У випадку casese, в якому було пошкоджено лише деякі дуже мало байт більше, ніж hdd, виникла зміна, за якою частка стилю 4096 байт має значущі дані.

Прикладом може бути те, що 4096 являє собою графіки ASCII з 2 речень. Тоді цілком можливо, що капелюх із 1 речення або більше повністю недоторканий. Крім того, можливо, що кожне 2-е чи 3-е букви було перекреслено. Якщо дані 4096 втрачаються у події URE, це означає, що їх інтерпретація залежить від даних. Можна було б уявити, що в самих даних є ще один шар оболонки ECC, який би дозволив подальше відновлення.

Тому добре, що більшість прошивок трактують сектори URE інакше, ніж погані сектори:

Зазвичай автоматичне перекомпонування секторів відбувається лише тоді, коли записується сектор. Логіка, що стоїть на цьому, імовірно, що навіть якщо сектор не може бути прочитаний нормально, він все ще може бути прочитаний методами відновлення даних. (з https://en.wikipedia.org/wiki/Bad_sector )

Або, якщо врахувати це, можливо, що частина сектора все ще містить корисні дані.