Обнаружение и исправление гниения бита

17

Я собираюсь реорганизовать все свои жесткие диски в моем домашнем Linux-боксе и хотел бы использовать mdadm raid для защиты данных и его гибкость для изменения формы массивов. Однако прежде чем использовать mdadm для этого, я бы хотел узнать, как он справляется с гниением . В частности, виды гниения битов, которые не приводят к тому, что с жесткого диска отправляются неустранимые сообщения об ошибках чтения.

Учитывая , что я , вероятно , буду использовать по крайней мере 21TB жестких дисков на 8 дисков в наса и различных котировках на вероятности из неудач на жестких дисках, я думаю , что во время восстановления из строя одного диска я с достаточной степенью вероятностью столкновения некоторая форма гниения на оставшихся дисках. Если это неустранимая ошибка чтения на 1 из дисков, что диск фактически сообщает об этом как об ошибке, я считаю, что это должно быть хорошо с raid6 (не так ли?). Однако, если данные, считанные с диска, неверны, но не сообщаются как таковые на диске, то я не вижу, как это можно автоматически исправить даже с помощью raid6. Это то, что нам нужно беспокоиться? Учитывая статью 2010 и RAID5 все еще работаети мой собственный успешный опыт дома и на работе, вещи не обязательно такие мрачные и мрачные, как можно было бы заставить поверить в модные слова и маркетинг, но я ненавижу восстанавливать из резервных копий только из-за сбоя жесткого диска.

Учитывая, что шаблоны использования будут: писать не чаще нескольких раз и время от времени читать, мне нужно будет выполнить очистку данных . Я вижу в вики archlinux команды mdadm для очистки данных как

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

затем следить за прогрессом

cat /proc/mdstat

Мне кажется, что он будет читать все сектора всех дисков и проверять, соответствуют ли данные четности и наоборот. Хотя я замечаю, что в документах делается сильный акцент на том, что существуют значительные обстоятельства, по которым операция «проверка» не сможет выполнить автоматическое исправление, только обнаружение, и пользователь сможет ее исправить.

Какой уровень (ы) RAID mdadm мне следует выбрать, чтобы максимизировать мою защиту от бит-гнили, и какие действия по обслуживанию и другие защитные меры мне следует предпринять? И от чего это меня не защитит?

Изменить: я не ищу, чтобы запустить RAID против ZFS или любой другой технологии QA. Я хочу знать конкретно о рейде mdadm. Вот почему я спрашиваю о Unix и Linux, а не о SuperUser .

Редактировать: ответ: mdadm может исправлять только URE, о которых сообщают дисковые системы во время очистки данных, и обнаруживать тихую битовую гниль во время очистки, но не может / не сможет это исправить?

BeowulfNode42
источник
Что касается защиты данных, главное преимущество, которое я вижу в zfs, - это очистка дискового пространства файлов при каждом чтении файла. Вот почему я сейчас настроил его с помощью zfs. Но мне все равно нужно регулярно выполнять полный скраб. У меня есть 2 пула zfs в каждом с 3 дисками, и я хочу обновить систему до 8 дисков, где любой диск может выйти из строя, и все равно будет еще 1 резервный диск, а zfs не может использоваться для такого изменения формы. Так как я все равно перестраиваюсь, я снова посещаю mdadm.
BeowulfNode42
Вам повезло с RAID5 / 6 до сих пор. Дело в том, что сейчас 2013 год, а RAID все еще страдает от дыры в записи. Если вы теряете мощность после того, как данные записаны, но до записи четности, то вы просто испортили свои хорошие данные, и возможно, что из-за несоответствия ваш массив тоже является тостом. Спасибо RAID5.
Багамат
Дело в том, что то, что вы хотите сделать, лучше всего делать на уровне файловой системы. В противном случае вам понадобится какой-то способ обнаружения и, предпочтительно, исправления гниения битов, возможно, в ситуации с пониженным резервированием или без избыточности, а RAID просто не подходит для этого. Мало того, что нет никакой гарантии, что вы все равно не получите гниль (что произойдет, если один диск выйдет из строя, а другой прочитает бит неправильно с диска?), Но простой RAID также не имеет понятия о том, что является важными данными и что такое просто шум. Поскольку ZFS очищает только данные, на которые есть ссылки , гниль на неиспользованной части диска становится не проблема.
CVN
На самом деле, вы не можете ожидать, что случайная файловая система поверх нескольких дисков (даже с избыточностью) внезапно защитит вас от сбоев хранилища. Я не нахожусь в священном крестовом походе, чтобы довести ZFS до широких масс (хотя я действительно считаю, что это отличное изобретение, и я использую его на Linux в основном для всего, кроме корневого раздела, который является ext4 на mdraid1 для совместимости программного обеспечения), но Я также признаю, что ваша проблема является одной из тех, которые ZFS была разработана с нуля для решения: гарантированное обнаружение и, если возможно, исправление повреждения данных независимо от причины.
CVN
Я думаю, что вы должны пересмотреть свои требования. Вы действительно нуждаетесь в защите битрот даже в том случае, если применяется коррекция ошибок? Знаете ли вы, насколько маловероятно, чтобы битрот существовал ДАН, что он также был исправлен с помощью ECC диска?
пещерный человек

Ответы:

5

Честно говоря, я нахожу довольно удивительным, что вы отказались от RAIDZ2 ZFS. Кажется, он почти идеально подходит для ваших нужд, за исключением того факта, что это не Linux MD. Я не нахожусь в крестовом походе, чтобы довести ZFS до широких масс, но простой факт заключается в том, что ваша задача - это одна из тех проблем, которые ZFS была разработана с нуля для решения. Использование RAID (любого «обычного» RAID) для обеспечения обнаружения и исправления ошибок, возможно, в условиях пониженной или полной избыточности, кажется рискованным. Даже в ситуациях, когда ZFS не может исправить ошибку данных должным образом, она может, по крайней мере, обнаружить ошибку и сообщить вам, что существует проблема, позволяющая предпринять корректирующие действия.

Вы не должны делать регулярные полные скрабы с ZFS, хотя это и рекомендуется. ZFS проверит, что данные, прочитанные с диска, соответствуют тому, что было записано во время чтения данных, и в случае несоответствия либо (а) использует избыточность для восстановления исходных данных, либо (б) сообщит об ошибке ввода-вывода в приложение. Кроме того, очистка - это оперативная операция с низким приоритетом, весьма отличная от проверки файловой системы в большинстве файловых систем, которая может быть как высокоприоритетной, так и автономной. Если вы используете скраб и что-то кроме скраба хочет выполнить ввод / вывод, скраб займет заднее сиденье на время. Очистка 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), заменив диски на диски большей емкости и предоставив полную возможность восстановления.

CVn
источник
5
В своем первоначальном вопросе я пытался избежать аргумента zfs vs raid, так как об этом много информации. Я хочу конкретную информацию о mdadm. Кроме того, поскольку я не буду читать все данные достаточно часто, чтобы обеспечить регулярную очистку данных, мне потребуется регулярно выполнять полную очистку массива независимо от zfs или raid.
BeowulfNode42
@ BeowulfNode42 лично я предлагаю использовать контрольные суммы прикладного уровня для исключительно важных данных (например, используйте sha256 для проверки ваших важных данных). ZFS может делать это за блок, что, на мой взгляд, является излишним. Я думаю, это объясняет, почему не так много контрольных сумм файловых систем, как ZFS, потому что, по моему мнению, это скорее проблема прикладного уровня.
пещерный человек
1
@ пещерный человек, я не знаю о тебе; Мне действительно нравится тот факт, что мне не нужно постоянно проверять файлы контрольных сумм, чтобы быть уверенным, что они не были повреждены. Конечно, в подавляющем большинстве случаев нет коррупции , и в этом случае никакого вреда нет (с ZFS вы выбираете алгоритм выбора контрольной суммы из нескольких, поэтому вы можете выбрать предпочитаемую точку в континууме безопасности / производительности), но Автоматические контрольные суммы на уровне файловой системы гарантируют, что нет неисправленного повреждения, потому что, если оно есть, вы будете знать об этом, в случае ZFS, получив ошибку ввода-вывода вместо поврежденных данных.
CVn
@ MichaelKjörling Нет, это не «гарантирует» (только снижает вероятность необнаруженных ошибок относительно проверок только на диске на величину, которую еще никто не определил! Поэтому никто не знает, насколько полезна проверка контрольных сумм ZFS :)), плюс Вы можете использовать простые оболочки «чтение» и «запись», которые прозрачно выполняют контрольные суммы для вас. Не нужно помещать эту причудливую вещь в пространство ядра.
пещерный человек
3
@caveman нет, zfs не по теме. Также не возможны реализации RAID, которые не являются mdadm. Я хочу знать о mdadm. Я уже проголосовал за этот ответ столько, сколько смогу, и ваши комментарии к ответу не по теме, заполняющему дополнительную информацию об ответе не по теме, не помогают с первоначальным вопросом.
BeowulfNode42
3

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

Многие накопители используют ECC (коды с исправлением ошибок) для обнаружения ошибок чтения. Если данные повреждены, ядро ​​должно получить URE (неисправимая ошибка чтения) для этого блока с диска, поддерживающего ECC. При таких обстоятельствах (и есть исключение ниже) копирование поврежденных или пустых данных поверх надежных данных может привести к безумию. В этой ситуации ядро ​​должно знать, какие данные хорошие, а какие плохие. Согласно 2010 и RAID5 все еще работает ... статья:

Рассмотрим эту альтернативу, которая, как я знаю, будет использоваться, по крайней мере, несколькими поставщиками массивов. Когда диск в томе RAID сообщает о URE, контроллер массива увеличивает счетчик и удовлетворяет вводу / выводу, восстанавливая блок из проверки на четность. Затем он выполняет перезапись на диске, который сообщил URE (возможно, с помощью verify), и если сектор поврежден, микрокод будет переназначен, и все будет хорошо.

Тем не менее, теперь за исключением: если диск не поддерживает ECC, диск лжет о повреждении данных или микропрограммное обеспечение особенно неисправно, то URE может не сообщаться, а поврежденные данные будут передаваться ядру. В случае несовпадения данных: кажется, что если вы используете двухдисковый RAID1 или RAID5, то ядро ​​не может знать, какие данные являются правильными, даже когда они находятся в не ухудшенном состоянии, поскольку существует только одна четность блок и не было зарегистрированного URE. В трехдисковом RAID1 или RAID6 один поврежденный блок, не помеченный URE, не будет соответствовать избыточной четности (в сочетании с другими связанными блоками), поэтому правильное автоматическое восстановление должно быть возможным.

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

sudoman
источник
1
Я думал, что все современные HDD имеют некоторую форму внутреннего ECC. Является ли это эффективным, правильным или неисправным - это другой вопрос. ECC должен использоваться внутри накопителя, чтобы иметь возможность сообщать URE. Молчаливый гниль, который меня больше всего интересует, не сообщает URE даже на дисках, которые его поддерживают, так как считают, что у них есть правильные данные, когда их нет.
BeowulfNode42
Под битой гнили я предполагаю, что вы имеете в виду биты, которые случайно переключаются. В любом случае ECC предназначен для обнаружения перевернутых битов. Согласно Википедии, исправление ошибок Рида-Соломона является распространенным форматом ECC, изобретенным в 1960 году, и до сих пор используется в дисках Blu-Ray + HDD. Если вы обнаружите, что этот алгоритм чрезвычайно надежен, то на ваш вопрос следует ответить в значительной степени, так как приличное современное оборудование, по определению, так же хорошо, если не лучше, даже если вы не знаете приличия аппаратного обеспечения просто так. смотря на это.
Судоман
1
Битовая гниль также может возникать из-за других проблем, например, когда из-за какой-то проблемы головки диска не выровнены должным образом в том месте, где, по их мнению, они пишут, и перетекают в соседние сектора. Это может исправить сектор, над которым он собирался работать, но соседний сектор будет поврежден. Если случится так, что он записал поверх data + ecc таким образом, что ECC для соседнего сектора сообщает, что он в порядке, то накопитель никогда не узнает, что у него есть проблема. Гораздо более вероятно, что какое-то мошенническое программное обеспечение инструктирует диск для записи неверных данных, жесткий диск будет верно хранить эти плохие данные. например, плохая команда дд
BeowulfNode42
2

Для защиты, которую вы хотите, я бы пошел с RAID6 + обычное резервное копирование в 2-х местах.

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

djsmiley2k во тьме
источник
1
но какие возможности обнаружения / исправления гниения бит это предлагает?
BeowulfNode42
1
RAID6 с частой очисткой обеспечивает некоторую защиту от гниения, так как двойная четность эффективно создает три версии одного и того же блока, поэтому можно провести «голосование», какая версия верна. AFAIK, очистка RAID6 в linux dm-raid делает именно это, пожалуйста, поправьте меня, если я ошибаюсь.
П.Петр
1
@ P.Péter Я понимаю, что математика может использовать систему голосования, но mdadm? Знаете ли вы какие-либо документы по этому поводу или имели личный опыт, который привел вас к такому выводу. Особенно в свете ответа Итана.
BeowulfNode42
Это было некоторое время назад, но я смутно помню, как читал о механизмах mdadm RAID6, прежде чем комментировать. Извините, не очень конкретно. :( Я думаю, что мы могли бы использовать настоящего эксперта по mdadm ...
P.Peter
2

У меня недостаточно представителей, чтобы комментировать, но я хочу отметить, что система mdadm в Linux НЕ исправляет никаких ошибок. Если вы скажете ему «исправлять» ошибки во время очистки, скажем, RAID6, если есть несоответствие, он «исправит» его, предполагая, что порции данных правильные и пересчитывая четность.

Итан
источник
1
Это кажется маловероятным, если я не понимаю вас. Вы имеете в виду, что данные из поврежденных блоков часто копируются в правильные блоки? Для этого потребуется, чтобы поврежденный блок не исходил от диска, поддерживающего ECC (и, следовательно, не сообщал бы о URE), и чтобы вы использовали RAID5 или 2 копии RAID1 (вместо RAID6, как вы предложили).
sudoman
@sudoman, во время очистки, если подсистема Linux MD обнаруживает несоответствие между данными и четностью, она слепо предполагает, что четность неверна, и перезаписывает ее на основе данных. Можно использовать двойной четность RAID 6, чтобы выяснить, что не так, но подсистема Linux MD этого не делает.
Марка
1
Итан, я не думаю, что у тебя есть ссылки на эту информацию? или примеры личного опыта вы готовы поделиться тем, что вы помните? Учитывая переплетение, которое произвел этот Q, даже полезная информация была бы полезна. С тех пор, как этот Q был опубликован, у меня были некоторые проблемы с mdadm RAID1 для загрузочного диска, на (дешевых) USB-флешках, когда 1 из них вышел из строя. Некоторое исследование позже указывает на то, что у неисправного USB-флешки недостаточно памяти или какой-либо проверки ошибок, или просто не удалось записать данные в некоторые блоки и не возникла ошибка записи. Пришлось переустанавливать ОС.
BeowulfNode42
-2

немного гниль фуд. конечно...

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

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

это продолжается до тех пор, пока у вас не закончатся запасные части (жесткий диск, умный), а затем УМНЫЕ крики КОНЕЦ ЖИЗНИ. (или даже более рано, как HP), скажем, на контроллере HP P420, он наблюдает за этим все время. Мой даже пишет мне по электронной почте, показывая БЛИЖАЙШИЕ ИЗ ЗАПАСНЫХ кластеров. Иногда запасные части идут намного быстрее, что является верным признаком гибели в ближайшее время, (10 лет, конечно, меньше в старом сате.

Я называю BOGUS, и FUD на гниль.

Я думаю, что кто-то игрушечный компьютер записал данные неправильно, по каким-либо причинам. не работает память ECC ?? К сожалению, реальные серверы имеют ECC RAM. вирус заражен. или пропало питание при записи (без ИБП>?)? или имеет плохую память.? или ESD поврежден. Или блок питания делает тонны шума (плохо)

Я называю FUD здесь. извиняюсь,

savvy2
источник
1
Я только что уточнил, что говорил о моей домашней системе, поэтому оборудование ECC и серверного уровня выходит за рамки моего бюджета. Моя домашняя лаборатория гораздо более склонна к неожиданным потерям энергии даже при ее мини-взлетах или других случайных событиях, таких как падение башни или что-то в этом роде. Есть много других способов сказать жесткому диску, что он хранит неправильные данные, а жесткий диск хранит биты ECC для этих неправильных данных. Мне все равно, как произошли ошибки, я хочу, чтобы они легко исправлялись.
BeowulfNode42