mdadm и периодический беспричинный recovering

что в смарте?

Чисто. Это на четырех совершенно разных машинах периодически происходит.

высокий ЛА?

Про то, что в debian/ubuntu переодически запускается checkarray знаете?

по крону оно раз в месяц запускается :). Сам был ф шоке...

На федоре раз в неделю!

Не понял что есть «ЛА». Диски здоровые, никаких причин периодической синхронизации не вижу. Более того, эта фигня происходит даже на совершенно новом сервере, которому двух месяцев нет.

>> Не понял что есть «ЛА».

LA.

никаких причин периодической синхронизации не вижу

В /etc/cron.* уже смотрел?

Кстати, покажи dmesg. Там должно быть «md: data-check of RAID». «active sync» это как-то подозрительно.

[53871037.103383] md: data-check of RAID array md0
[53871037.103383] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[53871037.103383] md: using maximum available idle IO bandwidth (but not more th
[53871037.103383] md: using 128k window, over a total of 4200896 blocks.
[53871037.105769] md: delaying data-check of md1 until md0 has finished (they sh
[53871037.108401] md: delaying data-check of md2 until md1 has finished (they sh
[53871037.108401] md: delaying data-check of md1 until md0 has finished (they sh
[53871082.537235] md: md0: data-check done.
[53871082.569211] md: delaying data-check of md2 until md1 has finished (they sh
[53871082.569211] md: data-check of RAID array md1
[53871082.569211] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[53871082.569211] md: using maximum available idle IO bandwidth (but not more th
[53871082.569211] md: using 128k window, over a total of 2104448 blocks.
[53871082.816233] RAID1 conf printout:
[53871082.816233] --- wd:2 rd:2
[53871082.816233] disk 0, wo:0, o:1, dev:sda1
[53871082.816233] disk 1, wo:0, o:1, dev:sdb1
[53871104.505300] md: md1: data-check done.
[53871104.526907] md: data-check of RAID array md2
[53871104.526907] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[53871104.526907] md: using maximum available idle IO bandwidth (but not more th
[53871104.526907] md: using 128k window, over a total of 1458830400 blocks.
[53871104.609686] RAID1 conf printout:
[53871104.609686] --- wd:2 rd:2
[53871104.609686] disk 0, wo:0, o:1, dev:sda2
[53871104.609686] disk 1, wo:0, o:1, dev:sdb2
[53943334.295466] md: md2: data-check done.
[53943334.372945] RAID1 conf printout:
[53943334.372945] --- wd:2 rd:2
[53943334.372945] disk 0, wo:0, o:1, dev:sda3
[53943334.372945] disk 1, wo:0, o:1, dev:sdb3

в /ect/cron.d/mdadm в первое воскресенье месяца запускается checkarray, похоже это и является причиной, но вопрос «почему массив перестраивается» остается открытым:

/dev/md2:
Version : 00.90
Creation Time : Mon Sep 28 12:29:45 2009
Raid Level : raid1
Array Size : 1458830400 (1391.25 GiB 1493.84 GB)
Used Dev Size : 1458830400 (1391.25 GiB 1493.84 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Sun May 1 06:00:00 2011
State : clean, recovering
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Rebuild Status : 20% complete

UUID : 9d11c8e8:bacd5f6d:776c2c25:004bd7b2
Events : 0.148

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3

>> вопрос «почему массив перестраивается» остается открытым

Если мне не изменяет память, в том скрипте делается repair, а не check. Фактически, это тот же check (т.е. r/o) до тех пор, пока не найдётся несоответствий — тогда они будут устранены (check ошибки не исправляет). В общем, эта операция реально ничего не перестраивает, если массив в порядке.

В dmesg написано data-check, значит это не rebuild. Возможно это глюк самого mdadm. Надо в /proc/mdstat смотреть, мало ли что mdadm пишет...

Угу, и я соврал: checkarray не делает repair вообще.

Вообще, очень интересно что происходит. mdadm пишет «State : clean, recovering». В сырцах есть

static char *sync_action[] = {", recovering",", resyncing",", reshaping",", checking"};

Т.е., по идее, он должен писать что-то вроде clean, checking. Однако он всё же пишет recovering. Тут, похоже, «одна из черепашек пи$дит». Надо будет проверить что на самом деле делает check. Может он действительно втихаря ребилдит массив...

>> Однако он всё же пишет recovering.

Да, у меня тоже %) Однако по скорости и шуму дисков понятно, что никакой записи всё же не происходит. В /proc/mdstat всё пишется правильно.

Можешь отправить багрепорт? Как-то им писал, они даже отвечают. Я щас малец занят :(

Сформулировать суть проблемы я могу, но у меня нет более веских обоснований для выводов о деятельности ядра, кроме скорости и шума %) А если допустить, что вместо check делается repair, то это требует дополнительных тестов. ИМХО, тут надо вооружаться отладчиком, а это несколько за пределами моих навыков.

Дополнительно могу уточнить, что «recovering» в выводе mdadm -D пишется только при check, при repair и rebuild/resinc пишется одно и то же — «resyncing».

Хотя, можно и без средств отладки всё надёжно проверить, но это требует определённого времени. Завтра могу попробовать, если не будет других дел :)

>Однако по скорости и шуму дисков понятно, что никакой записи всё же не происходит.

Вы можете отличить звук линейного чтения от звука линейной записи? :)

>> Вы можете отличить звук линейного чтения от звука линейной записи?

По крайней мере на некоторых дисках. Почему звук разный, не знаю.

Итак, попробовал протестировать на вшивость check в виртуалке. Собрал массив, синхронизировал, забил мусором из /dev/urandom, остановил массив, посчитал md5 для цепочки из 100 блоков по 512 байт на обоих устройствах, на одном из дисков переписал эти блоки, запустил проверку — даже в mismatch_cnt ноль, хотя массив заведомо неконсистентен. С тем же результатом repair o_O На физической машине такого бреда не было, хотя ОС и весь софт те же самые. Не знаю, почему так, но проверять на хосте не очень тянет, ибо долго выйдет.