Проверить RAID 1 mdadm

Может это поможет протестировать: Существенный прогресс в проекте ZFS для FreeBSD (комментарий)

Если подобное сделать на zfs, то zfs вообще ничего не покажет. Да что уж там, можно всего лишь испортить один блок и нет больше zfs.

Они пишутся, можешь не беспокоиться оь этом. Вот по поводу идентичности данных на компонентах массива, если не используется Btrfs или ZFS, беспокоиться стоит.

проверку, по очереди на каждом диске

Ты явно путаешь дисковый массив высокой доступности и бекапы.

Бесполезно это говорить, пускай сам ощутит на своих данных.

Правда что ли?

Что будет, если записать всего лишь один «корневой» блок с испорченными данными, но с правильной контрольной суммой. Типичный сплит-брейн? Что будет при коллизии, когда разные блоки имеют одинаковые контрольные суммы?

Ты тоже путаешь бекапы с высокой доступностью. Рассматриваешь сценарии, когда дисковый массив испортили, когда он не выполняет свои функции - выключен.

Что будет, если записать всего лишь один «корневой» блок с испорченными данными, но с правильной контрольной суммой.

Такое может произойти лишь в результате осознанных действий, а файловые системы проектируются для защиты от кривого железа.

Что будет при коллизии, когда разные блоки имеют одинаковые контрольные суммы?

Пересчитать и сравнить обе. Если это реальная коллизия — написать авторам ФС, что они идиоты.

Такое может произойти лишь в результате осознанных действий

Выключение массива, зануление - это бессознательное действие?

Если это реальная коллизия

Посчитаешь вероятность коллизий 1024-байтной контрольной суммы для 64 килобайтных блоков для равномерного распределения? Допустим, «равномерно распределенная реальность».

И да эти «контрольные суммы» мало чего полезного гарантируют в отличии кодов обнаружения и коррекции ошибок.

Для RAID1 нет такого «проверить каждый диск», но есть «проверить массив».

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

«Проверить», ты хотел сказать? Потому что сначала ты видишь ненулевое mismatch_cnt. Гуглишь, оказывается, это «нормально». Но, допустим, есть причины подозревать bit rot. Тут выясняется, что в этих классических педальных RAID1 просто нельзя понять, где правильная копия. Приехали :)

Для RAID1 нет такого «проверить каждый диск», но есть «проверить массив».

Искусственно привести физически каждый диск в негодность. Мало-ли что-то с БП или еще что. Думаю смысл передал

Мальчики и девочки, вам нужен консенсус

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

И вам русским языком сказано как именно проверить в онлайне не снижая отказоустойчивость.

Array check это сделает сам наиболее корректным способом.

Array check это сделает сам наиболее корректным способом. echo check > /sys/block/mdX/md/sync_action

Этот процесс я запустил, сейчас проверяет, массив новый, диски всё равно пустые, думал проверить тестовым файлом. Но точно ли будет всё ок, если один из дисков посыпется? И второй вопрос, если один из дисков прийдётся запустить в другой системе, он запуститься со всеми данными ?

У всех дисков давно есть контрольные суммы и они вам просто не отдадут искаженных данных. Ну а если вы в компонент массива записали «что-то» - то тут уж ССЗБ, что записали - то и получили.

Если у вас диск не degraded, всё у вас будет нормально. Только не забудьте указать, что разрешено монтирование деградировавших массивов (по умолчанию запустить деградировавший массив можно только явно указав соответствующий ключ, сделано во избежание потенциального сплитбрейна)

Только не забудьте указать, что разрешено монтирование деградировавших массивов

Я массив собираю первый раз) Как это сделать? С учётом того что уже собрал.

У всех дисков давно есть контрольные суммы и они вам просто не отдадут искаженных данных.

Есть, да. Да, просто возьмут и отдадут, как обычно это и делают 🤷🏻‍♀️ ZFS, Btrfs, покойную ReFS и таргет dm-integrity придумали параноики, конечно же, если бы они только знали о волшебных контрольных суммах в накопителях :)

У всех дисков давно есть контрольные суммы

И самое главное, что эти контрольные суммы (которые на самом деле коды коррекции ошибок ECC) занимают около 20%+ объема. По сравнению с «контрольными суммами» во всяких бла-бла-fs (которые около 1% от данных) они реально что-то делают - проверяют и исправляют возникающие ошибки.

массив новый, диски всё равно пустые,

Тобишь установлена голая ОС?

Тобишь установлена голая ОС?

Причём тут ОС? Новый массив из пустых дисков.

Новый массив из пустых дисков

Уточняю-новый Массив на работающем сервере?

Уточняю-новый Массив на работающем сервере?

Да. Массив будет просто монтироваться в каталог для файлов

Если массив инициализирован и прошел первоначальную синхронизацию - всё будет нормально. И даже если не прошел - тоже, просто нет гарантий что те блоки в которые не записывали будут идентичны. Но те в которые запись уже прошла при собранном (не обязательно даже синкнутом) массиве тоже будут иметь идентичные данные, с точностью до последнего [f]sync()

Контрольные суммы верхнего уровня (в ФС) это защита от идиота который может переписать данные не через уровень массива /dev/md*** а напрямую в компонент. Если вы не идиот - то есть не покупаете днищежелезо которое потом еще и оверклочите и андервольтите, и не лупите записью куда попало - то они вам не особо нужны.

Что будет, если записать всего лишь один «корневой» блок с испорченными данными, но с правильной контрольной суммой.

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

Если данные можно взять со второго диска в зеркале, то ZFS не покажет проблемы, а вернёт запрошенный файл и тихо перезапишет его запорченные блоки на проблемном диске. В фоне. Если проблема будет повторяться раз за разом, то ZFS сообщит о проблеме в девайсе.

Если массив инициализирован и прошел первоначальную синхронизацию - всё будет нормально.

Да, прошла синхронизация, прошел «Check». Сейчас в стутусе «clean» и 2 диска в статусе «Active sync»

Ясно, отдыхай. Еще один фанат «контрольной суммы».

Контрольные суммы верхнего уровня (в ФС) это защита от идиота

В принципе, дальше тут обсуждать нечего, уровень понимания работы I/O от софта до физического уровня понятен :/

то есть не покупаете днищежелезо

Я просто напомню, что ZFS создавалась под энтерпрайзное железо, прямо конкретно под большие дисковые полки вращающейся ржавчины. У которого silent corruption — добрая традиция. Потому что прошивки и для дисков, и, особенно, для контроллеров писали и пишут обезьянылюди, которым не чужды ошибки. Это тебе кажется просто, что если что-то реализовано «в железе», то оно по определению надёжно, а на самом деле это территория эталонного говнокода. Даже всякие оффлоады в контроллерах, про которые можно сказать, что они в железе, нередко реализуются с ошибками.

Я просто напомню, что ZFS создавалась под энтерпрайзное железо

И что, в zfs все построено на магических «контрольных суммах», или на методах похожих на raid?

В случае с ZFS, ты получишь ошибку, а не тихое повреждение данных.

Хочешь сказать, что entrerprise hdd хуже consumer hdd?

Нет, только то, что они не имеют никакой волшебной защиты от порчи данных.

они не имеют никакой волшебной защиты от порчи данных

А вот zfs имеет благодаря волшебным контрольным суммам!

tl;dr Берегите информацию, а диски пусть mdadm бережет :)

На самом деле, я бы с этим не заморачивался особо. И вот почему: контроль состояния дисков - задача mdadm и свою задачу он будет выполнять исправно.

Но нам, как пользователям, важно другое - данные файловой системы, то бишь, информация.

И вот эту информацию надо бекапить. При полном бекапе произойдет проверка ВСЕХ файлов. Но если делать частые полные бекапы затратно, то можно просто эмулировать сам процесс, например:

tar c /mnt/mystorage > /dev/null

Тогда можно будет спать спокойно.

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

А так, raid1 - это для уменьшения простоев при аварии диска, в первую очередь.

P.S. В одной мелкой торговой конторе, что аутсорсил мой бывший работодатель, однажды сдох один из дисков в raid1. Так я успел даже по гарантии его заменить на новый, а юзеры даже ничего и не заметили - работали в своих 1С себе дальше с одним диском. И я не парился, ибо бекапы делались исправно.

контроль состояния дисков - задача mdadm и свою задачу он будет выполнять исправно.

mdadm ничего не проверяет. Ты ещё пошути, что он с обоих частей зеркала читает для проверки(нет, он так не делает). Единственный способ заставить mdadm проверить данные - это запустить scrub и смотреть на счётчик mismatch_cnt.

А я и не говорю о проверке данных, а лишь о состоянии дисков - «живой» он или нет.

Наоборот, я сказал, данные (информацию) надо бекапить и проверять сам бекап.

Про состояние дисков живы они или не очень smartd расскажет в лицах.

Само собой, если нужны подробности.

Без если.

Если диск faulty, то это уже не важно.

У диска может быть больше двух состояний живой/мертвый.

Ага, а у людей больше двух гендеров. Вот только кому они de facto нужны :)

«Не-живому» диску дорога на гарантию или на полку. Это все в рамках обсуждения raid, конечно. А для торрентов, например, можна всяких доходяг юзать, не спорю.

«Подающему признаки возможной смерти» диску дорога на гарантию или на полку.

А когда заканчивается место для ремапов сбойных секторов, диск считается конченным, так? :))

Смотря какие цели преследуем. Намекаю на сам вопрос, что ждем когда место для ремапа закончиться :)

«Подающему признаки возможной смерти»

Это все в рамках обсуждения raid, конечно.

Внезапно, да.

На самом деле, я бы с этим не заморачивался особо. И вот почему: контроль состояния дисков - задача mdadm и свою задачу он будет выполнять исправно.

Ну а если вот перепад напряжения, или мало-ли что и выходит со строя материнка к примеру? Или SSD с системой даёт сбой. Как можно «завести» один из дисков с файлами на ноуте к примеру, и вытащить данные?

По поводу бэкапов - согласен и понимаю. Хочу потом взять 3-тий диск для этого дела, и хранить вообще выключенным отдельно, переодически делая их.

периодические полные бекапы активировать

Случайно нет ссылки на какую-то статью, где это расписывают?

Ну а если вот перепад напряжения, или мало-ли что и выходит со строя материнка к примеру? Или SSD с системой даёт сбой. Как можно «завести» один из дисков с файлами на ноуте к примеру, и вытащить данные?

Ух, ну это прям «Пункт назначения», если и диск, и материнка полетели одновременно. Никогда с таким не сталкивался, но даже подключив один исправный диск из «зеркала» на другой машине командой типа:

mdadm --assemble --readonly /dev/md0 /dev/sdX

Должен найтись raid в деградированном состоянии. Его можно смонтировать и вытянуть данные.

Но вот как раз в таких ситуациях восстановление из бекапа на новую машину было бы банально быстрее.

Случайно нет ссылки на какую-то статью, где это расписывают?

Увы, не подскажу универсального рецепта. Но, например, в UrBackup была опция периодических полных бекапов, включается просто в web-интерфейсе сервера бекапов, ЕМНИП. Я UrBackup старался использовать, потому что там принцип работы клиент-сервер. Сторонний софт доступ к бекапам не имеет. Это была киллер-фича в те времена, тогда как раз бушевали вирусы-шифровальщики.