Проблема с mdraid 6 под centos 6.

все переменные по скорости в /sys/block/.. стоят на максе.

А можно конкретнее?

Ещё неплохо было бы увидеть dmesg.

Иван,

Да. Конечно.

blockdev --setra 65536 /dev/md126

echo 4096 > /sys/block/md126/md/stripe_cache_size

echo 100000 > /sys/block/md126/md/sync_speed_min
echo 500000 > /sys/block/md126/md/sync_speed_max

echo 1 > /sys/block/md126/md/sync_force_parallel

echo 150000 > /proc/sys/dev/raid/speed_limit_min
echo 500000 > /proc/sys/dev/raid/speed_limit_max

[   21.644493] md: bind<sdh1>
[   21.645238] md: bind<sdg1>
[   21.646224] md: bind<sdm1>
[   21.647465] md: bind<sdn1>
[   21.648891] md: bind<sda1>
[   21.650415] md: bind<sdb1>
[   21.652402] md: bind<sdi1>
[   21.654367] md: bind<sdl1>
[   21.656526] md: bind<sdc1>
[   21.663665] md: bind<sdj1>
[   21.666500] md: bind<sdk1>
[   21.691553] raid6: sse2x1   gen() 11542 MB/s
[   21.708548] raid6: sse2x1   xor()  9197 MB/s
[   21.725545] raid6: sse2x2   gen() 14503 MB/s
[   21.742541] raid6: sse2x2   xor() 10347 MB/s
[   21.759541] raid6: sse2x4   gen() 16808 MB/s
[   21.776539] raid6: sse2x4   xor() 12328 MB/s
[   21.776540] raid6: using algorithm sse2x4 gen() 16808 MB/s
[   21.776541] raid6: .... xor() 12328 MB/s, rmw enabled
[   21.776542] raid6: using ssse3x2 recovery algorithm
[   21.777525] async_tx: api initialized (async)
[   21.778583] xor: automatically using best checksumming function:
[   21.788534]    avx       : 31836.000 MB/sec
[   21.796555] md: raid6 personality registered for level 6
[   21.796556] md: raid5 personality registered for level 5
[   21.796557] md: raid4 personality registered for level 4
[   21.796708] md/raid:md126: not clean -- starting background reconstruction
[   21.796710] md/raid:md126: reshape will continue
[   21.796734] md/raid:md126: device sdk1 operational as raid disk 6
[   21.796735] md/raid:md126: device sdj1 operational as raid disk 4
[   21.796735] md/raid:md126: device sdc1 operational as raid disk 2
[   21.796736] md/raid:md126: device sdl1 operational as raid disk 10
[   21.796737] md/raid:md126: device sdi1 operational as raid disk 8
[   21.796738] md/raid:md126: device sdb1 operational as raid disk 1
[   21.796739] md/raid:md126: device sda1 operational as raid disk 0
[   21.796739] md/raid:md126: device sdn1 operational as raid disk 9
[   21.796740] md/raid:md126: device sdm1 operational as raid disk 7
[   21.796741] md/raid:md126: device sdg1 operational as raid disk 5
[   21.796742] md/raid:md126: device sdh1 operational as raid disk 3
[   21.797160] md/raid:md126: allocated 11772kB
[   21.797171] md/raid:md126: raid level 6 active with 11 out of 11 devices, algorithm 2
[   21.797171] RAID conf printout:
[   21.797172]  --- level:6 rd:11 wd:11
[   21.797173]  disk 0, o:1, dev:sda1
[   21.797173]  disk 1, o:1, dev:sdb1
[   21.797174]  disk 2, o:1, dev:sdc1
[   21.797174]  disk 3, o:1, dev:sdh1
[   21.797175]  disk 4, o:1, dev:sdj1
[   21.797176]  disk 5, o:1, dev:sdg1
[   21.797176]  disk 6, o:1, dev:sdk1
[   21.797177]  disk 7, o:1, dev:sdm1
[   21.797178]  disk 8, o:1, dev:sdi1
[   21.797178]  disk 9, o:1, dev:sdn1
[   21.797179]  disk 10, o:1, dev:sdl1
[   21.797280] created bitmap (15 pages) for device md126
[   21.797490] md126: bitmap initialized from disk: read 1 pages, set 3 of 29807 bits
[   21.829719] md126: detected capacity change from 0 to 16002075066368
[   21.829744] md: reshape of RAID array md126
[   21.829747] md: minimum _guaranteed_  speed: 100000 KB/sec/disk.
[   21.829748] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reshape.
[   21.829755] md: using 128k window, over a total of 1953378304k.

А когда вообще это началось? Ведь судя по «reshape = 33.0%», почти треть оно успешно зарешейпило. Делалось ли что-то с системой или с рейдом после начала процесса?

Ещё вопрос: идёт ли нагрузка на этот массив?

Как раз после 33% и подвисло все. Сейчас массив отмонтировал, т.к. диски все в 100%. В общем то, понятно почему решейпинг подвис. Проблема в битмапе. Он же содержит карту массива. А массив решейпится. Т.е. на каждое изменение в массиве, ему приходится обновлять карту. А т.к. карта внутренняя (internal bitmap), то получаем большую проблему в виде перманентного цикла. До 33% дисковая подсистема (кернел модуль) еще справлялась с обновлением и карты и решейпингом. А далее, уже все. 100% загрузка ядра. И т.к. md_raid6 не тредится на все ядра, то получается что приплыли.
Вот и думаю что делать..((

А если принудительно перевести в idle через sysfs и отрубить bitmap?

Сейчас массив отмонтировал, т.к. диски все в 100%.

В смысле «в 100%»?

В общем то, понятно почему решейпинг подвис.

И почему же?

Проблема в битмапе. Он же содержит карту массива. А массив решейпится. Т.е. на каждое изменение в массиве, ему приходится обновлять карту. А т.к. карта внутренняя (internal bitmap), то получаем большую проблему в виде перманентного цикла. До 33% дисковая подсистема (кернел модуль) еще справлялась с обновлением и карты и решейпингом. А далее, уже все. 100% загрузка ядра. И т.к. md_raid6 не тредится на все ядра, то получается что приплыли.

Тут ты глупость написал. Internal bitmap просто медленнее и всё. Он не должен приводить к падению скорости решейпа до нуля.

ИМХО это либо баг, либо ты что-то очень странное сделал.

Пробывал. Дисковая подсистема подвисает, и на следующие запросы уже не реагирует.

Сейчас массив отмонтировал, т.к. диски все в 100%.

В смысле «в 100%»?

Util 100% каждого диска в массиве по информации iostat. Т.е. ядро загружено дисковыми запросами на 100%.

Тут ты глупость написал. Internal bitmap просто медленнее и всё. Он не должен приводить к падению скорости решейпа до нуля.

Это просто была одна из мыслей, если исходить из того что битмап содержит как-раз информацию о массиве, а тот постоянно изменяется. Да, кстати если мне не изменяет память, кажется в вики по mdraid писали о том, что необходимо грохнуть битмап перед решейпингом. Да и я ранее, всегда его грохал перед обновлением массива.
Может конечно и баг, но что-то я на трекере не видел трабл с mdraid 6 для centos 6.9.

Есть мысли по решению траблы? Может все-таки попробовать заново его построить в нужном порядке? Есть правда еще идея SATA кабели проверить. Может в них проблема. Хотя, dmesg бы об этом писал конечно..

поставьте нормальный дистр и не мучайтесь

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

О каком постоянном изменении идет речь? Там только помечаются «грязные» области массива размером в bitmap-chucksize (в данном случае 64Mb), в которые идет запись. Reshape только добавляет изменение 2ух битов bitmap каждые $bitmap-chucksizeMb reshaping'а (т.е. каждые 64Mb), в остальном же она будет обновляться с такой же частотой, как и до reshape, т.е. в зависимости от частоты записи и от того, как часто запись идет в разные 64Mb области.

Да, кстати если мне не изменяет память, кажется в вики по mdraid писали о том, что необходимо грохнуть битмап перед решейпингом.

И правильно пишут, но причина в первую очередь другая. Меняется размер массива, соответственно понадобятся дополнительные биты в битмапе, чтобы покрыть его новый размер, но зарезервированной области для internal bitmap'ы может на это не хватить. Поэтому правильно сначала ее убрать, провести reshape и потом заново добавить bitmap'у с уже, возможно, большим шагом, чтобы хватило на нее места. Ну а уже второй причиной является разгрузка массива: отключением internal bitmap снизим wiops на диски, соответственно больше woips будет доступно для reshape и он сможет завершиться быстрее.

Лично у меня возникла следующая идея. Загрузиться в init /bin/sh, и далее пересоздать массив со всеми дисками в нужном порядке, c assume clean

Ага, и получить только 33% начальных данных, которые зарешейпились (если собрать вместе с новым диском), или 67% последних данных, которые не успели зарешейпиться (если собрать только изначальное количество дисков). Если что-то такое и делать, то пришлось бы собирать 2 разных массива, разделенных по границе остановки решейпинга и потом эти массивы линейно склеивать device-mapper'ом.

[======>..............] reshape = 33.0% (644716212/1953378304) finish=23865280.9min speed=0K/sec

Смотрим /sys/block/md126/md/sync_max, ограничена ли область синка. Если ограничена, то можно скорректировать на всю область массива: echo max > /sys/block/md126/md/sync_max

Это может быть потенциально опасно, по хорошему сначала бы выяснить, из-за чего там осталось ограничение, возможно как раз не хватает размера битмапы на больший объем. А возможно было выставлено еще до решейпа из-за какой-то другой причины.

Util 100% каждого диска в массиве по информации iostat. Т.е. ядро загружено дисковыми запросами на 100%

100% в iostat значит только то, что за весь период измерения было всегда больше одной незавершенной io опрерации.

Util 100% каждого диска в массиве по информации iostat. Т.е. ядро загружено дисковыми запросами на 100%.

Эта цифра скорее всего ничего не значит. В отличие от CPU, у блочных устройств нет чётко определённого потолка занятости работой. Что конкретно понимают под «100%» разработчики iostat мне неведомо.

Есть мысли по решению траблы?

Нормальных идей лично у меня нет. Гуглятся решения вроде

echo max > /sys/block/mdN/md/sync_max

mdadm --grow --continue /dev/mdN

Может все-таки попробовать заново его построить в нужном порядке?

Раньше я вообще считал, что --assume-clean имеет смысл только для raid1 и raid10. Но теперь вот не уверен. В любом случае, есть риск просрать все данные.

uuborn, Иван,

Спасибо за правильные комменты. Что касается области синка, то она максимальная:

[root@home ~]# cat /sys/block/md126/md/sync_max
max

Util 100% каждого диска в массиве по информации iostat. Т.е. ядро загружено дисковыми запросами на 100%

100% в iostat значит только то, что за весь период измерения было всегда больше одной незавершенной io опрерации.

Согласен. Только я смотрю на это вместе с тем, что ядро забито на 100%. Т.е.,скопилась очередь из операций на обработку ядром. В результате, возникла проблема с самим доступом к дискам. Например, сейчас операции на запись через /sys/block вообще не работают с данным массивом. Просто виснут.
В общем, остается одно решение. Действительно делать два массива, раздельно. И далее, уже собирать их вместе.
В выходные, начну заниматься. Посмотрю, что и как.
Спасибо, коллеги!

С Наступающим!

Поставьте нормальный дистр и не мучайтесь

Да-да, вы совершенно правы...