WARNING: mismatch_cnt is not 0 on /dev/md2

Это сообщение в CentOS посылает CRON задача /etc/cron.weekly/99-raid-check.

Внутри этого скрипта есть вызов, для проверки этого самого mismatch_cnt:

cat /sys/block/md2/md/mismatch_cnt
2048

Судя по интернетам, это число обозначает число не синхронизированных по какой причине секторов. Как я понимаю, это косвенно намекает на проблемы с винтом и необходимость его замены, так что обязательно проверьте все винты SMART. Если с ними все ок, то можно повторить CHECK (см. ниже) и счетчик ошибок обнулится.

Из документации ядра (Documentation/md.txt) следует следующее:

mismatch_count
When performing 'check' and 'repair', and possibly when
performing 'resync', md will count the number of errors that are
found. The count in 'mismatch_cnt' is the number of sectors
that were re-written, or (for 'check') would have been
re-written. As most raid levels work in units of pages rather
than sectors, this my be larger than the number of actual errors
by a factor of the number of sectors in a page.

Но из этого совершенно нихрена не понятно, что за ошибки-то эти и какова их природа. Комментарии в коде немного проливают свет на происходящее,

sector_t resync_mismatches; /* count of sectors where
* parity/replica mismatch found
*/

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

Далее в коде ядра встречается следующее (в функции sync_request_write):

/* We have read all readable devices. If we haven't
* got the block, then there is no hope left.
* If we have, then we want to do a comparison
* and skip the write if everything is the same.
* If any blocks failed to read, then we need to
* attempt an over-write
*/

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

Далее в коде идет memcmp (сравнение участков памяти) всех секторов с первичного устройства со всеми соответствующими секторами на ведомом и если при этом найдены отличные сектора, идет инкремент mismatch_cnt :

mddev->resync_mismatches += r1_bio->sectors;

Но, судя по коду, с такими секторами ничего не делается. Отсюда мораль - большое значение mismatch_cnt означает проблемы с дисками. И по возможности диски надо побыстрее заменить.

Кстати, в папочке md есть еще много всяких интересностей:

ls /sys/block/md2/md/
array_state dev-sda3 level new_dev rd1 suspend_hi sync_completed sync_speed_min
chunk_size dev-sdb3 metadata_version raid_disks resync_start suspend_lo sync_speed
component_size layout mismatch_cnt rd0 safe_mode_delay sync_action sync_speed_max

Отсюда по Гуглу (http://www.linuxshare.ru/docs/admin/ud_sraid.html) находится ряд интересных фич:

Выполнить проверку целостности массива:

echo 'check' >/sys/block/md2/md/sync_action

Отменить запланированную проверку массива:

echo 'idle' >/sys/block/md2/md/sync_action

Выполнить ресинхронизацию массива:

echo 'repair' >/sys/block/md2/md/sync_action

Заключение
Вообще, по нашему опыту использования софт-рейдов (я сейчас только про SOFT RAID-1), значения mismatch_cnt в пределе нескольких тысяч можно игнорировать абсолютно без вреда для данных и стабильности систем. У нас таких массивов около 15 штук и никаких проблем с ними нету совершенно.