Ладно. После обычной очистки мой MDADM RAID5 сообщает о mismatch_cnt = 16. Как я понимаю, это означает, что, хотя ни одно устройство не сообщило об ошибке чтения, есть 16 блоков, для которых данные и четность не совпадают.
Вопрос №1: Можно ли получить список этих блоков?
Вопрос №2: Предполагая, что №1 возможно, учитывая, что базовая файловая система - EXT4, есть ли способ определить, какие файлы связаны с этими блоками?
У меня действительно есть оперативные резервные копии, и в идеальном мире я мог бы просто сравнить живой массив с данными резервной копии, чтобы найти любые файлы, которые были незаметно повреждены. Но реальность такова, что отзыв 6 ТБ данных резервного копирования был бы непомерно дорогим и трудоемким. Знание, где искать и что восстанавливать, значительно упростило бы жизнь.
(Следует отметить, что я запускаю очистку RAID только с опцией «check». Запуск scrub с опцией «repair» кажется ужасно опасным, потому что MDADM знает только, что данные или четность неверны, но не знает, какие именно. Таким образом, вероятность того, что MDADM ошибается и восстанавливает неверные данные, составляет 50%. Отсюда мое желание знать, какие файлы потенциально затронуты, чтобы при необходимости я мог восстановить их из резервной копии)
Любые предложения приветствуются!
Извините, проверка действительно выполняет обратную запись в массив, когда обнаруживает ошибку - см. https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file/usr/share/doc/mdadm/README.checkarray
'check' - это операция только для чтения, даже если в журналах ядра может быть указано иное (например, / proc / mdstat и несколько сообщений ядра будут упоминать «повторную синхронизацию»). См. Также вопрос 21 FAQ.
Если, однако, во время чтения возникает ошибка чтения, проверка вызовет нормальный ответ на ошибки чтения, который заключается в генерации «правильных» данных и попытке их записи - так что вполне возможно, что «проверка» вызовет написать. Однако при отсутствии ошибок чтения он доступен только для чтения.
... так что, возможно, уже слишком поздно собирать данные, которые вы ищете, извините.
В долгосрочной перспективе стоит отметить, что RAID5 (и 6, и 1) имеют нет защиты от гнили это, вероятно, ситуация, с которой вы столкнулись. Когда данные на одном диске портятся, у них нет возможности определить, какие из данных хорошие, а какие плохие. Я бы посоветовал запланировать переход на файловую систему, которая проверяет контрольные суммы каждого диска, например, btrfs или zfs.
(RAID-5 действительно не следует использовать в новых развертываниях - и действительно очень не должно быть там, где емкость сырых дисков превышает 2 ТБ каждый - см. http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/)