Q: MDADM mismatch_cnt> 0. Есть ли способ определить, какие блоки не согласны?

12

Ладно. После обычной очистки мой MDADM RAID5 сообщает о mismatch_cnt = 16. Как я понимаю, это означает, что хотя ни одно устройство не сообщило об ошибке чтения, существует 16 блоков, для которых данные и четность не согласуются.

Вопрос № 1: Можно ли получить список этих блоков?

Вопрос № 2: Предполагая, что № 1 возможен, учитывая, что базовой файловой системой является EXT4, есть ли способ определить, какие файлы связаны с этими блоками?

У меня есть резервные копии на ближней линии, и в идеальном мире я мог бы просто сравнить живой массив с данными резервных копий, чтобы найти любые файлы, которые были незаметно повреждены. Но реальность такова, что резервное копирование 6 ТБ данных будет непомерно дорогим и отнимает много времени. Знание, где искать и что восстанавливать, значительно упростит ситуацию.

(Должен заметить, что я запускаю очистку RAID только с опцией 'check'. Запускать очистку с опцией 'repair' кажется ужасно опасным, потому что MDADM знает только, что данные или четность неверны, но не знает, какие именно. Таким образом, представляется вероятным, что 50% вероятности того, что MDADM угадает и восстанавливает неверные данные. Поэтому я хочу знать, какие файлы потенциально могут быть затронуты, чтобы я мог восстановить их из резервной копии, если это необходимо)

Любые предложения с благодарностью!

linux mdadm arcasinky
источник
проверить dmesgили / var / log / syslog?
Псуси
Здравствуй. Насколько я могу судить, единственными сообщениями, записанными в системный журнал скруббером, были сообщения начала и остановки. Сообщения о несоответствиях не зарегистрированы.
arcasinky
Смотрите icheck+ ncheckв debugfsдля идентификации файлов на основе смещения сектора.
Щ
Я попытался добавить запись для номера сектора. Сейчас я пытаюсь выяснить, что делать дальше: unix.stackexchange.com/questions/266432/…
Питер Кордес
2
Я ничего не знаю, говорит, что диски плохие, но проверь их. Используйте пакет smartmontools, чтобы сделать это для каждого диска (как в smartctl -a /dev/sdaи т. Д.), Или используйте любой другой метод, чтобы запустить короткий тест SMART на каждом диске и распечатать полный отчет. Весьма вероятно, что один из них умирает, и для того, чтобы вызвать общую тревогу о состоянии здоровья SMART, требуется серьезный ущерб.
Спулер

Ответы:

1

Извините, 'check' действительно записывает обратно в массив при обнаружении ошибки - см. 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 и в нескольких сообщениях ядра будет упоминаться "resync"). Также см. Вопрос 21 в FAQ.

Однако, если во время чтения происходит ошибка чтения, проверка вызовет нормальный ответ на ошибки чтения, который должен сгенерировать «правильные» данные и попытаться записать это - так что возможно, что «проверка» вызовет написать. Однако при отсутствии ошибок чтения он доступен только для чтения.

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

В более долгосрочной перспективе стоит отметить, что RAID5 (и 6, и 1) не имеют защиты от бит-гнили, которая, вероятно, является ситуацией, с которой вы столкнулись. Когда данные на одном диске становятся плохими, у них нет никакого способа определить, какая из данных хорошая против плохой. Я бы посоветовал планировать переход на файловую систему, которая проверяет контрольные суммы каждого диска, например, btrfs или zfs.

(RAID-5 действительно не следует использовать в новых развертываниях - и действительно не следует использовать там, где емкость необработанных дисков превышает 2 ТБ каждый - см. Http://www.zdnet.com/article/why-raid-5- перестает работать в 2009 году / )

Эндрю В
источник