виявлення та виправлення гнит біт за допомогою mdadm

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

З огляду на , що я , ймовірно , буду використовувати принаймні 21TB жорстких дисків на 8 дисків в наса і різних котируваннях на ймовірності з невдач на жорстких дисках, я думаю , що під час відновлення з ладу одного диска я з достатньою ступенем ймовірністю зіткнення якась форма бітової гнилі на решти дисках. Якщо це невідправна помилка читання на 1 з накопичувачів, що привід насправді повідомляє про це як про помилку, я вважаю, що це має бути добре з raid6 (це?). Однак якщо дані, прочитані з диска, погані, але не повідомляються як такі на диску, я не можу побачити, як це можна автоматично виправити навіть при raid6. Це щось, про що ми повинні турбуватися? З огляду на статтю It is 2010, і RAID5 все ще працює , і мої власні успішних досліди будинку і на роботі, то не обов'язково , як і песимізм як слівця і маркетинг нас би повірив, але я ненавиджу відновлюватись із резервних копій лише тому, що жорсткий диск вийшов з ладу.

З огляду на , що моделі використання будуть, записи в більшості кілька разів, і читати час від часу, я повинен буду виконувати дані скрубери . Я бачу на wiki Archlinux команду mdadm для очищення даних масиву як

echo check > /sys/block/md0/md/sync_action

потім слідкувати за прогресом

cat /proc/mdstat

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

Який рівень (-и) RAID mdadm слід вибрати, щоб забезпечити максимальну захист від бітової гнилі та які заходи з технічного обслуговування та інших захисних заходів потрібно робити? І від чого це мене не захистить?

Редагувати: Я не хочу запускати RAID проти ZFS або будь-якої іншої технології QA. Я хочу знати конкретно про рейд mdadm. Ось чому я прошу в Unix & Linux, а не в SuperUser .

Редагувати: це відповідь: mdadm може виправити лише URE, про які повідомляють дискові системи під час скрабування даних та виявляє беззвучне гниття бітів під час скрабу, але не може / не зможе це виправити?

Чесно кажучи, мені здається, що ви дивно відхиляєте RAIDZ2 ZFS. Це здається, що відповідає вашим потребам майже ідеально, за винятком того, що це не Linux MD. Я не на хрестовому поході, щоб довести ZFS до маси, але простий факт полягає в тому, що ваша - це одна з тих проблем, які ZFS був розроблений з нуля для вирішення. Покладатися на RAID (будь-який "регулярний" RAID) для забезпечення виявлення та виправлення помилок, можливо, у ситуації зі зменшеним або відсутністю надмірності здається ризикованим. Навіть у ситуаціях, коли ZFS не може правильно виправити помилку даних, вона може принаймні виявити помилку та повідомити про наявність проблеми, що дозволяє вжити коригувальних дій.

Вам не доведеться робити регулярні повні скраби з ZFS, хоча це рекомендується. ZFS перевірить, що дані, прочитані з диска, відповідають тому, що було записано під час зчитування даних, а у разі невідповідності або (a) використовувати надмірність для реконструкції вихідних даних, або (b) повідомити про помилку вводу / виводу для додаток. Крім того, скрабування - це операція в Інтернеті з низьким пріоритетом, що зовсім відрізняється від перевірки файлової системи в більшості файлових систем, яка може бути як високооборотною, так і офлайн. Якщо ви використовуєте скраб і щось інше, ніж скраб хоче зробити введення / виведення, скраб буде займати заднє місце протягом тривалості. Скруб ZFS займає місце як скрабу RAID, так і метаданих і даних файлової системи перевірка цілісності, тому набагато більш ретельна, ніж просто очищення масиву RAID для виявлення будь-якої бітової гнилі (яка не говорить вам, чи мають дані якісь сенси, а лише те, що вони записані правильно контролером RAID).

Надлишок ZFS (RAIDZ, дзеркальне відображення, ...) має перевагу в тому, що невикористані місця на диску не потрібно перевіряти на відповідність під час скрабування; під час скрабу перевіряються лише фактичні дані, оскільки інструменти проходять ланцюг блоку виділення. Це те саме, що і з резервним резервом. Для "звичайного" RAID всі дані (включаючи невикористані місця на диску) повинні бути перевірені, оскільки контролер RAID (будь то апаратне чи програмне забезпечення) не має уявлення про те, які дані насправді актуальні.

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

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

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

Єдиний справжній мінус полягає в тому, що ви не можете легко виростити RAIDZ vdev, додавши до нього пристрої. Для цього є обхідні шляхи, які зазвичай включають такі речі, як розріджені файли, як пристрої в vdev, і дуже часто називають "я б цього не робив, якби це були мої дані". Отже, якщо ви їдете по маршруту RAIDZ (незалежно від того, чи їдете ви з RAIDZ, RAIDZ2 або RAIDZ3), вам потрібно визначитися, скільки дисків ви хочете в кожному vdev. Незважаючи на те, що кількість накопичувачів у vdev фіксовано, ви можете рости vdev поступово (переконуючись у межах порогу надмірності vdev), замінюючи накопичувачі на більші ємності та дозволяючи повний resilver.

Ця відповідь є результатом міркувань на основі різних доказів, які я знайшов. Я не знаю, як працює реалізація ядра Linux, оскільки я не розробник ядра, і там, мабуть, є велика кількість безглуздих дезінформацій. Я припускаю, що ядро ​​Linux робить розумний вибір. Моя відповідь повинна застосовуватися, якщо я не помиляюся.

Багато дисків використовують ECC (коди для виправлення помилок) для виявлення помилок читання. Якщо дані пошкоджені, ядро ​​повинно отримати URE (непоправну помилку читання) для цього блоку від підтримуючого накопичувача ECC. За цих обставин (і тут є виняток нижче), копіювання пошкоджених або порожніх даних над хорошими даними може означати божевілля. У цій ситуації ядро ​​повинно знати, що є хорошими даними, а які - поганими. Згідно з програмою It is 2010 і RAID5 все ще працює ... стаття:

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

Однак тепер для винятку: якщо накопичувач не підтримує ECC, на диску накопичується пошкодження даних або прошивка особливо не працює, то URE може не повідомлятися, а пошкоджені дані надаватимуться ядру. У випадку невідповідності даних: здається, що якщо ви використовуєте 2-дисковий RAID1 або RAID5, то ядро ​​не може знати, які дані є правильними, навіть якщо вони не в деградованому стані, оскільки існує лише один паритет блок, і не було повідомлено про URE. У 3-дискових RAID1 або RAID6 один пошкоджений блок, який не позначений URE, не відповідав би надмірному паритету (у поєднанні з іншими асоційованими блоками), тому належне автоматичне відновлення повинно бути можливим.

Мораль історії полягає в тому, щоб використовувати диски з ECC. На жаль, не всі диски, що підтримують ECC, рекламують цю функцію. З іншого боку, будьте обережні: я знаю когось, хто використовував дешеві SSD в 2-дисковому RAID1 (або 2 копії RAID10). Один із приводів повертав випадкові пошкоджені дані при кожному зчитуванні певного сектору. Пошкоджені дані були автоматично скопійовані над правильними даними. Якщо SSD використовував ECC і працював належним чином, ядро ​​повинно було вжити належних коригувальних дій.

Для захисту, яку я хотів би, я б перейшов з RAID6 + нормальне резервне копіювання за межами сайту в двох місцях.

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

У мене недостатньо респондентів для коментарів, але я хочу зазначити, що система mdadm в Linux НЕ виправляє жодних помилок. Якщо ви скажете йому "виправити" помилки під час скрабування, скажімо, RAID6, якщо є невідповідність, він "виправить" це, вважаючи, що частини даних є правильними та перераховує паритет.

трохи гнила фуд. впевнений ...

Я думаю, вам потрібно поговорити з SEAGATE. (забудьте? це виправдання)? тепер усі накопичувачі мають 100-бітну корекцію ECC, яку вам потрібно довести в першу чергу.
Б'юсь об заклад, що ви не можете. (це турбуватися про FUD правильно?), як страх перед привидами чи №13? і не робиться тут. нульовий доказ трапився. і ще гірше - немає доказів причини.

Спочатку визначте, що означає бітова гниль. ой ... HDD: ECC перевіряє дані (навіть 1 біт) щодо 100-бітового сховища ECC. якщо це неправильно, він виправляє його, якщо він продовжує виходити з ладу двигуна SMART, напевно, на дисках SAS, він логічно замінює кластер або сектор на той, який є хорошим. за допомогою запасних кластерів. це відновлює шкоду. Так, всі диски зростають поганими бітами від першого до кінця, від першого диска IBM до СЕЙЧАС. але зараз ми займаємось самостійним ремонтом. Прочитайте повний документ White Seagate. нескінченні там, і дізнайтеся, як працює накопичувач. добре?

це триває, поки у вас не закінчиться запасних частин (hdd brain, smart), а потім SMART кричить кінець життя. (або навіть більш рано, як це робить HP), скажімо, контролер HP P420, він спостерігає за цим весь час. Мій навіть надсилає мені електронні листи, показуючи БЛИЗЬКИЙ РЕЗЕРВНИЙ кластер. Іноді запчастини проходять швидше, швидше за все, це впевнений знак (10 років, безумовно, менше у невдалій саті.

Я називаю BOGUS, а FUD на біт гнилі.

Думаю, хтось із іграшкових ПК записав дані неправильно, з будь-яких причин. не працює пам'ять ECC ?? На жаль, справжні сервери мають ECC RAM. вірусом заражений. або втратили живлення під час запису (немає UPS>?)? або має погану пам'ять. або пошкоджено ШОЕ. Або блок живлення видає тонни шуму (погано)

Я дзвоню сюди FUD. вибачте,