Чи справді проблема бітної гнилі на жорстких дисках? Що з цим можна зробити?

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

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

Це справжня проблема? А якщо так, то що з цим можна зробити? Мій друг рекомендує zfs як рішення, але я не уявляю, як згладжувати наші файлові сервери на роботі, надягаючи Solaris та zfs ..

По-перше: у вашій файловій системі можуть не бути контрольних сум, але на вашому жорсткому диску вони є. Наприклад, є SMART. Після того, як один біт занадто багато перевернувся, помилка, звичайно, не може бути виправлена. А якщо вам справді не пощастило, біти можуть змінитися таким чином, що контрольна сума не стане недійсною; тоді помилка навіть не буде виявлена. Отже, можуть статися неприємні речі ; але твердження про те, що випадкове перегортання бітів моментально пошкодить вам дані, є хибним.

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

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

Так чи інакше: ні, це неможливо виявити .

Але файлова система сама по собі ніколи не може бути гарантією того, що всі помилки можна буде відновити; це не срібна куля. Ви все ще повинні мати резервні копії та план / алгоритм, що робити, коли виявлена ​​помилка.

Так, це проблема, головним чином із збільшенням розмірів приводу. Більшість накопичувачів SATA мають коефіцієнт URE (нерегульована помилка читання) 10 ^ 14. Або для кожного 12 ТБ даних, прочитаних статистично, постачальник дисків каже, що накопичувач поверне помилку читання (зазвичай ви можете їх шукати на аркушах специфікацій накопичувача). Привід буде працювати нормально для всіх інших частин накопичувача. Enterprise FC & SCSI-накопичувачі зазвичай мають частоту URE 10 ^ 15 (120TB) разом з невеликою кількістю SATA-дисків, що сприяє його зменшенню.

Я ніколи не бачив, щоб диски перестали обертатися в той самий час, але у мене виникла об’єм raid5, який потрапив у цю проблему (5 років тому з PATA накопичувачами 5400RPM). Привід виходить з ладу, він відзначається мертвим, і відбувається відновлення запасного приводу. Проблема полягає в тому, що під час відновлення другий диск не в змозі прочитати той маленький блок даних. Залежно від того, хто робить рейд, весь обсяг може бути мертвим або просто той маленький блок може бути мертвим. Якщо припустити, що один блок мертвий, якщо ви спробуєте прочитати його, ви отримаєте помилку, але якщо ви напишете на нього, накопичувач переставить його в інше місце.

Існує кілька методів захисту від: raid6 (або еквівалент), який найкраще захищає від відмови у подвійному диску, додаткові - це файлова система, що знає URE, наприклад, ZFS, використовуючи менші групи рейдів, так що статистично у вас є менший шанс потрапити на диск URE. обмеження (великі дзеркальні накопичувачі або диски raid5 менших розмірів), очищення дисків і SMART також допомагають, але насправді не є захистом само по собі, але використовується як додаток до одного з перерахованих вище методів.

У мене є близько 3000 шпинделів в масивах, і масиви постійно очищають накопичувачі, які шукають приховану URE. І я отримую досить постійний потік з них (кожного разу, коли він знаходить один, він виправляє його перед помилкою накопичувача і попереджає мене), якби я використовував raid5 замість raid6, а один з накопичувачів вийшов повністю мертвим ... Я б бути у біді, якщо він потрапить у певні місця.

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

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

Залежно від деталей накопичувача, він навіть повинен мати можливість відновити з декількох перевернутих бітів у секторі. Буде обмежено кількість перевернутих бітів, які можна безшумно виправити, і, ймовірно, ще одне обмеження кількості перевернутих бітів, яке може бути виявлено як помилка (навіть якщо немає більше надійних даних, щоб їх виправити)

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

Сучасні жорсткі диски (починаючи з 199x) мають не лише контрольні суми, але й ECC, які можуть виявити та виправити досить «випадкову» бітну гниль. Дивіться: http://en.wikipedia.org/wiki/SMART .

З іншого боку, певні помилки в прошивці та драйверах пристроїв можуть також пошкоджувати дані в рідкісних випадках (в іншому випадку QA вловлює помилки), які важко буде виявити, якщо у вас немає контрольних сум вищого рівня. Ранні драйвери пристроїв для SATA та NIC пошкодили дані як у Linux, так і в Solaris.

Контрольні суми ZFS переважно спрямовані на помилки програмного забезпечення нижчого рівня. Новіші системи зберігання / бази даних, такі як Hypertable, також мають контрольні суми для кожного оновлення для захисту від помилок у файлових системах :)

Теоретично це викликає занепокоєння. Це практично є причиною того, що ми зберігаємо резервні копії дітей / батьків / бабусь і дідусів. Щорічні резервні копії потрібно зберігати щонайменше 5 років, IMO, і якщо у вас випадок такого повернення далі, ніж файл, файл, очевидно, не так важливий.

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

Так, це проблема.

Це одна з причин, чому RAID6 зараз стає модною (а також збільшення розмірів HD збільшує час на відновлення масиву). Наявність двох блоків парності дозволяє отримати додаткове резервне копіювання.

Системи RAID тепер також роблять RAID Scrubbing, який періодично зчитує блоки дисків, перевіряє їхні паритети та замінює їх, якщо вважає блок поганим.

Що стосується заяви ОП про RAID, не розуміючи, які дані є добрими проти поганих.

Контролери RAID використовують як мінімум (непарні / парні) біти парності на кожній смузі даних. Це для всього; смуги даних на диску та смуги даних парності (резервного копіювання).

Це означає, що для будь-якого типу RAID, у якого є смуга надмірності (RAID 5/6), контролер може точно вказати, чи змінилася початкова смуга даних, а також, чи змінилася смуга даних надмірності.

Якщо ви вводите другу надлишкову смужку, як RAID6, у вас повинно бути три смужки даних, на трьох різних дисках вони стають пошкодженими, що відповідають однаковим фактичним даним файлу. Пам’ятайте, що більшість систем RAID використовують відносно невеликі смуги даних (128 кбіт або менше), тому шанси на “бітну гниль”, що вишикується до того ж 128 кбіт одного і того ж файлу, практично неможливий.

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

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