Чи можуть дані на жорстких дисках погіршуватися без попередження про пошкодження?

Ми всі турбуємося про те, щоб наші дані та файли були безпечними та недоторканими, але чи можливо, щоб дані були пошкоджені та доступні користувачеві без повідомлення чи попередження про проблему? Сьогоднішня посада SuperUser Q&A відповідає на запитання читача.

Сьогоднішня сесія запитань та відповідей приходить до нас люб'язно SuperUser - підрозділ Stack Exchange, групування веб-сайтів із запитаннями та відповідями на рівні спільноти..

Фото надано узагальненням (Flickr).

Питання

SuperUser reader topo morto хоче знати, чи можуть дані на жорстких дисках погіршуватися і отримати доступ без попередження про пошкодження:

Чи можливо, що фізична деградація жорсткого диска може призвести до того, що біти «перевернуть» вміст файлу без операційної системи, яка б помітила цю зміну і повідомила користувача про це під час читання файлу? Наприклад, чи може "p" (двійковий 01110000) в текстовому файлі ASCII змінитися на "q" (двійковий 01110001), тоді, коли користувач відкриє файл, вони бачать "q", не знаючи, що сталася помилка?

Мені цікаві відповіді, що стосуються FAT, NTFS або ReFS (якщо це має значення). Я хочу знати, чи операційні системи захищають користувачів від цього, або якщо ми повинні перевіряти наші дані на відхилення між копіями протягом часу.

Чи можуть дані на жорстких дисках погіршитися і отримати доступ без попередження про пошкодження?

Відповідь

Співробітник SuperUser Гунтрам Блох має відповідь для нас:

Так, є річ, яка називається дрібною гниллю. Але ні, це не вплине на користувача непоміченим.

Коли жорсткий диск записує сектор на пластини, він не просто записує біти таким же чином, як вони зберігаються в оперативній пам'яті, він використовує кодування, щоб переконатися, що немає жодних послідовностей, що є занадто довгими. Він також додає коди ECC, які дозволяють виправити помилки, які впливають на кілька бітів і виявляти помилки, які впливають на кілька бітів.

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

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

Якщо сектор може бути легко відремонтований, відремонтована версія може бути записана на диск, прочитана назад, а потім перевірена, щоб визначити, чи була помилка випадковою (тобто космічні промені тощо) або якщо існує систематична помилка з носієм.

Якщо жорсткий диск визначить, що у ЗМІ є помилка, вона перерозподіляє сектор.

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

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

Це одна з основних відмінностей між жорсткими дисками, які продаються як «настільні», «NAS / RAID» або «відеоспостереження» жорстких дисків. Жорсткий диск RAID може швидко відмовитися і змусити контролера відновити сектор, щоб уникнути затримки на стороні користувача. Настільний жорсткий диск буде продовжувати намагатися знову і знову, тому що користувач чекає кілька секунд, ймовірно, краще, ніж говорити їм дані втрачені. І відео жорсткий диск значення постійної швидкості передачі даних більше, ніж відновлення помилок, як пошкоджений кадр, як правило, навіть не помітили.

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

Я ніколи не був свідком однієї помилки біта себе, але я бачив багато жорстких дисків, де цілі сектори не вдалося.

Жорсткий диск буде знати, якщо щось не так з сектором, але він не буде знати, які біти не вдалося. Один біт, який зазнав невдачі, завжди буде виявлений ECC.

Зверніть увагу, що chkdsk та файлові системи, які автоматично ремонтують себе, не стосуються відновлення даних у файлах. Вони спрямовані на корупцію в структурі самої файлової системи, як різниця у розмірі файлу між записом каталогу та кількістю виділених блоків. Функція NTFS, що самозаймається, виявить структурні пошкодження та перешкоджатиме подальшому впливу на ваші дані, але не буде відновлювати дані, які вже пошкоджені.

Є, звичайно, інші причини, з яких дані можуть бути пошкоджені. Наприклад, погана оперативна пам'ять на контролері може змінити дані, перш ніж вона навіть буде відправлена на жорсткий диск. У цьому випадку жоден механізм на жорсткому диску не виявлятиме або відновлюватиме дані, і це може бути однією з причин пошкодження структури файлової системи. Інші причини включають в себе помилки програмного забезпечення, відключення під час запису на жорсткий диск (хоча це стосується журналювання файлової системи), або погані драйвери файлової системи (драйвер NTFS на Linux за промовчанням тривалий час, оскільки NTFS було зворотне не задокументовані, а розробники не довіряють власному коду).

Я мав такий сценарій один раз, коли програма зберігала всі свої файли на двох різних серверах у двох різних центрах обробки даних, щоб зберегти робочу копію даних, доступних за будь-яких обставин. Через кілька місяців ми помітили, що близько 0,1% всіх скопійованих файлів не відповідає контрольній сумі MD5, яку додаток зберігає у своїй базі даних. Це виявилося несправним волоконним кабелем між сервером і SAN.

Ці інші причини пояснюють, чому деякі файлові системи, такі як ZFS, зберігають додаткову інформацію про суму перевірки для виявлення помилок. Вони розроблені, щоб захистити вас від набагато більше речей, які можуть піти не так, як просто злегка гниття.

Маєте щось додати до пояснення? Звучить в коментарях. Хочете прочитати більше відповідей від інших технологічних користувачів Stack Exchange? Перегляньте повний потік обговорення тут.