разрядное обнаружение гнили и исправление с 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 + Normal Offsite Backup в 2 местах.

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

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

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

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

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

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

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

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

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

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

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

Я называю ПОДПИСЧИКОМ, а ФУДом на битой гнили.

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

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