Это один из кошмарных дней: виртуализированный сервер, работающий на Linux SW-RAID1, запускает виртуальную машину, которая обнаруживает случайные сбои сегментации в кажущихся случайными кодовых блоках.
Во время отладки я обнаружил, что файл дает разные суммы md5 при каждом запуске. Копнув глубже, я обнаружил следующее: необработанные разделы диска, составляющие зеркало RAID1, содержат 2 разницы в битах и приблизительно. На одном диске 9 секторов полностью пусты, а на другом заполнены данными.
Очевидно, Linux возвращает сектор с неопределенно выбранного диска из зеркального набора. Таким образом, иногда тот же сектор возвращается в норме, иногда возвращается поврежденный.
В документы сказать:
RAID не может и не должен защищать от повреждения данных на носителе. Следовательно, также не имеет смысла намеренно повреждать данные (например, с помощью dd) на диске, чтобы увидеть, как система RAID с этим справится. Скорее всего (если вы не повредите суперблок RAID), уровень RAID никогда не узнает о повреждении, но ваша файловая система на устройстве RAID будет повреждена.
Спасибо. Это поможет мне заснуть. : - /
Есть ли способ заставить Linux хотя бы обнаруживать это повреждение, используя контрольную сумму секторов или что-то в этом роде? Будет ли это обнаружено в настройке RAID5? В этот момент я хотел бы использовать ZFS или btrfs (как только он станет доступен без возможностей uber-admin)?
Редактировать: я не один.
Вы можете принудительно проверить (например) md0 с помощью
echo "check" > /sys/block/md0/md/sync_action
Вы можете проверить состояние теста с помощью
cat /sys/block/md0/md/sync_action
пока он возвращается check проверка выполняется, после возврата idle ты можешь сделать
cat /sys/block/$dev/md/mismatch_cnt
чтобы узнать, равен ли счетчик несоответствий нулю. Многие дистрибутивы автоматизируют эту проверку, чтобы она выполнялась, например, еженедельно для вас, точно так же, как большинство промышленных аппаратных RAID-массивов постоянно запускают ее в фоновом режиме (они часто называют это «очисткой RAID»), в то время как в противном случае массив простаивает. Обратите внимание, что согласно комментариям в файле автоматической проверки Fedora, записи RAID1 в ядре не буферизуются, и поэтому счетчик несоответствий может быть ненулевым даже для исправного массива, если массив смонтирован.
Поэтому стабилизация массивов путем выполнения этой проверки, когда виртуальная машина не работает, если это вообще возможно, вероятно, хорошая идея.
Я бы добавил, что согласен с документами, когда они говорят, что
RAID не может и не должен защищать от повреждения данных на носителе
Предполагается, что RAID защищает устройство от полного отказа; защита от дополнительных случайных отказов в элементах запоминающего устройства - это работа по проверке ошибок и повторному отображению блоков, что, вероятно, лучше всего выполнять в самом контроллере. Я счастлив, что документы предупреждают людей об ограничениях RAID, особенно если он реализован на ненадежных устройствах. Я обнаружил, что частые проверки работоспособности моих дисков с помощью smartctl помогают мне оставаться на вершине дисков, которые начинают показывать ошибки, которые приводят к рассинхронизации зеркал.
Вы это проверили? http://tldp.org/HOWTO/Software-RAID-HOWTO-6.html