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

Я собираюсь реорганизовать все свои жесткие диски в моем домашнем 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, о которых сообщают дисковые системы во время очистки данных, и обнаруживать тихую битовую гниль во время очистки, но не может / не сможет это исправить?

Честно говоря, я нахожу довольно удивительным, что вы отказались от 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), заменив диски на диски большей емкости и предоставив полную возможность восстановления.

Этот ответ является продуктом рассуждений, основанных на различных доказательствах, которые я нашел. Я не знаю, как работает реализация ядра 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 и функционировал должным образом, ядро ​​должно было предпринять соответствующие корректирующие действия.

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

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

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

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

Я думаю, вам нужно поговорить с 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 здесь. извиняюсь,