обнаружение и исправление бит-бит с помощью mdadm

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

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

  • Просмотр файлов из зеркального RAID вне устройства
  • Перегородка LVM не установлена
  • Что произойдет, если сбой операционной системы MDADM md0
  • Дублирование ошибки PV в GParted при попытке удалить настройку RAID1
  • Что означает «запасное» число mdadm?
  • Понимание того, почему в этом случае отправляются электронные письма DegradedArray
  • Учитывая, что шаблоны использования будут, пишите не чаще нескольких раз и иногда читайте, мне нужно будет выполнить очистку данных . Я вижу в вики-файле archlinux команды mdadm для очистки данных в массиве как

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

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

     cat /proc/mdstat 

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

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

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

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

  • понимание программного обеспечения Linux-суперблока RAID
  • Существующий mdadm RAID5 не монтируется, либо проблемный диск, либо Superblock
  • Linux + как проверить конфигурацию зеркала на linux red hat
  • Linux RAID - Superblocks отсутствует на всех дисках после обновления оборудования
  • Не удается загрузить в LUbuntu после настройки RAID
  • mdadm: ПРОГРАММА всегда запускается пользователем root?
  • 4 Solutions collect form web for “обнаружение и исправление бит-бит с помощью mdadm”

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

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

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

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

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

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

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

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

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

    Linux и Unix - лучшая ОС в мире.