Расскажите про риски и реальные случаи проблем при операции grow linux raid

linux raid6

mdadm ?

Раз в месяц по cron'у запускается проверка рейда ( не rebuild, а т.н. recheck - mdadm читает блоки с дисков и убеждается, что нет ошибки контрольных сумм

В это время производительность обычных операций резко падает. дома я могу себе это позволить, но в проде это непозволительно

Это очень большая проблема, особенно на больших дисках и в проде. На хабре была печальная статья, как это обнаружили ВНЕЗАПНО и в результате архитектора уволили. «Если вам дороги жизнь и рассудок, держитесь подальше от торфяных болот программных рейдов». Аппаратные рейды себе подобного не позволяют

Предложил бы zfs-on-linux на замену, но его выкинули из ядра и угрожают судом ... Не знаю, чем можно заменить

Дальше, grow это всегда риск. Занимает часы, и нужно гарантировать что электричество в это время не пропадёт

Нда, блин.

На хабре была печальная статья, как это обнаружили ВНЕЗАПНО и в результате архитектора уволили

https://habr.com/en/post/139368/

Нда, блин. Грабли - они везде. Это приблизительно такая же ситуация, как с тем багом, на который я наступил. Если коротко, убунту руинит примонтированные ФС, если есть трафик на интелевском вай-фай-bt-адаптере. Это явно баг, но всех похрен.

Спасибо, я обязательно протестирую вариант с проверкой массива.

По идее скорость recheck'а ограничивается параметрами sysctl

dev.raid.speed_limit_min
dev.raid.speed_limit_max

Но задаётся именно скорость ( кб/с ), а не iops'ы

Если есть возможность потестировать на чём-то некритичном, посмотри, может производительность и устроит ( для проверки запусти «echo check > /sys/block/$MDADM_RAID/md/sync_action )

Главное не надо сразу на проде. Ну и капитанский тезис - за свои решения отвечаешь именно ты, а не вендор

dev.raid.speed_limit_max реально работает?

У меня давно rhel 7.4 клал на цифры и выжирал всю доступную полосу, попутно вынося всех, кто был на массиве. С тех пор прямо совсем стремно в линуксе что-то синхрячить, благо пока и не нужно было.

Слушай, но ведь это 2012 год же? Ситуация не улучшилась? Недавно же вроде стэки ядра переписывались.

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

Аппаратные рейды себе подобного не позволяют

А как насчет замены здохшего диска?