FastNetMon

Sunday 4 April 2010

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 штук и никаких проблем с ними нету совершенно.

7 comments :

  1. спасибо, помогло быстро разобраться.

    ReplyDelete
  2. Всегда пожалуйста :)

    ReplyDelete
  3. Выполнил синхронизацию. Но mismatch_cnt остался без изменений 1024

    ReplyDelete
  4. Заметил интересную особенность (на 2-х различных серверах) - если диски которые рейде(raid1) аппаратно располагаются prmaster-prslave то неизбежно появляются mismatch_cnt, если же prmaster-secmaster то ошибок нет.

    ReplyDelete
  5. У меня такое вылазит в основном для раздела, где живёт /boot и mismatch_count всегда 128 (а на этом разделе как правило ничего не меняется). Так что я согласен с тем, что это можно просто игнорировать, если число небольшое.

    ReplyDelete

Note: only a member of this blog may post a comment.