Скорость i/o падает в ноль во время проверки RAID6

Задай ему лимит скорости скраба чтобы он не ушатывал диск нагрузкой

https://www.kernel.org/doc/html/v4.15/admin-guide/md.html

смотреть в сторону ограничения sync_speed_max

Контролировать загрузку через iotop

Если поможет - забить понравившееся значение в sysctl

Давай проверим, правильно ли я понял.

Раз в месяц происходит запуск scrub. Пока этот scrub не дошел до половины, все работает нормально. А как только доходит, то скорость I/O падает в ноль как для scrub’а, так и для приложений.

Если это так, то это очень похоже на умирающий диск. Знать бы какой именно. Предлагаю, пока scrub’а нет, для всех дисков по очереди запустить от root вот эту команду:

pv /dev/sda > /dev/null

и следить за скоростью, которую она показывает. Если оно доходит до конца без ошибок и серьезных просадок, диск здоров.

А вообще HDD для использования в RAID’е нужны особые, промышленные. Обычные домашние не подходят. Разница в том, что промышленные HDD, как только столкнутся с плохо читаемым сектором, быстро возвращают ошибку, чтобы RAID без лишних задержек прочитал данные с другого диска. Домашние же модели пытаются до последнего разглядеть, что это там записано, так как «знают», что другой копии нет, и что при ошибке пользователь будет недоволен.

Разница в том, что промышленные HDD, как только столкнутся с плохо читаемым сектором, быстро возвращают ошибку, чтобы RAID без лишних задержек прочитал данные с другого диска.

Значительная часть консюмерских НЖМД тоже так умеет, man scterc.

Изначально проверка зависала на 60-65%. Я подумал как и вы. Прогнал эти диапазоны секторов через викторию на всех дисках и ошибок никаких не было.

Т.е проблема в длительности нагрузки.

Грешил на перегрев дисков (грелись до 55 при макс допустимой 60). Поставил корзину с обдувом и пару проверок прошло без проблем! Но теперь опять стало зависать. Похоже была какая-то связь с температурой дисков.

К слову жесткие диски специальные, для nas хранилищ. Предназначены для работы в raid массивах.

Ограничил макс. скорость до 40% от максимальной в начале диска, в конце будет ~85%.

Запустил проверку, через 20 часов должна закончится. Отпишусь по результатам

iostat -x 5
понаблюдай, какой диск дольше всего обрабатывает запросы, тот и дохнет.

К слову жесткие диски специальные, для nas хранилищ.

А какие именно диски? Может, SMR? А то некоторые производители (WD) были уличены в тихой поставке SMR дисков для NAS.

Seagate st8000vn004. Когда покупал специально искал не SMR.

Если вы про параметр r_await то в среднем 90-140 по всем дискам

А в dmesg есть что-нибудь?

Логи можно посмотреть только после перезапуска, а поскольку отваливается i/o логи записаться не могут)

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

Нет, dmesg - это kernel log, в оперативке.

смотреть надо когда глючить начнет.
у глючного диска время обработки запроса вырастет до секунд.
а параметр %util (он последний) будет показывать 100 %.
у меня так.

У меня тоже так было где-то 10 лет назад, решил отключением scrub-а насовсем. Пользы от него почти никакой не вижу, а зря грузить диски даже раз в месяц - незачем.

При ребилде развалится твой рейд. Скрабить надо. Чтобы умирающие диски находить раньше. А не позже.

Скрабить надо

а тут некоторые утверждали, что надо мониторить смарт и при появлении первых бэдов срочно-срочно менять диск.

Чтобы бэд появился, нужно хотя бы прочитать сектор. А кто его прочитает, если диски не скрабить.

А смарт мониторить надо, да. Менять ли при появлении первых бэдов диск, это уже дело каждого, диски могут жить долго с несколькими плохими секторами. Но лучше про этот факт знать, чем не знать.

Умирающие диски находятся и так. Потому что обычно они умирают целиком а не посекторно, и это заметно при всех операциях. А если «умирание» это битые сектора в каких-то рандомных местах, то вероятность того что 1) ты их не замечаешь + 2) они совпали между несколькими дисками массива - исчезающе мала.

Умирающие диски находятся и так.

Вообще скраб делается не только для нахождения умирающих дисков, а для проверки (и восстановления на FS с чексуммами) холодных данных. В массивах главное - находящиеся на них данные, а не диски.

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

На всех дисках есть контрольные суммы секторов, что там может незаметно повредиться?

Легко. Что и происходит довольно много. https://www.techadvisor.com/article/741570/bit-rot-how-to-avoid-the-slow-death-of-hard-drives-and-ssds.html

Вообщем проверка прошла успешно. Похоже действительно проблема была в длительной и высокой нагрузке на диски. Всем спасибо.

Умирающие диски находятся и так. Потому что обычно они умирают целиком а не посекторно

Десктопные могут и сразу умереть, от слова совсем. Серверные гораздо реже, но случается и мгновенная смерть. Во всех остальных случаях, мониторим смарт и при первых признаках отправляем в утиль.

Не мгновенная смерть, а то что признаки проблем либо видны вообще в целом, когда проблемы с электроникой или с механикой, либо ограничены конкретными секторами, вероятность которым совпасть с соседним диском минимальна, особенно если эти секторы никто не читает (если читают - опять же заметят быстро). Про смарт это и так всё понятно, речь была про другое.

Не мгновенная смерть

Возможно вы меня не поняли. Повторю по другому, десктопные мрут даже не сказав мяу по смарту, т.е. ни по какому показателю смарта. У серверных такое встречается, но очень редко. Но! тоже встречается. Но! Редко :)

Какая занимательная статья, для избежания битфлипов предлагает мониторить смарт, и регулярно покупать новые диски. Ну или использовать вместо них bluray, рядом разумеется рекламная ссылка где их купить. Ну и несколько сеошных ссылок на другие статьи сайта, скорее всего настолько же бесполезные.

Впрочем, главное там указано ближе к началу (но после дурацкой видеовставки): у дисков есть ECC, который работает полностью автономно и, если только не совсём всё плохо, всегда успешно исправляет такие штуки. Так что конечному пользователю беспокоиться не о чем, если только его не волнуют риски, шанс которых примерно раз в миллион лет.

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

Не смотрел, но полностью поддерживаю подобное изложение.

Ну, контроллер может повредиться, да. Но в контексте темы это не важно. Сторонники scrub-а боятся что диск испортится как то так что, с одной стороны, это будет совершенно незаметно при регулярном его использовании, а с другой - повреждения настолько большие, что пересеклись с соседним диском, который тоже незаметно, но сильно повредился. Мгновенная сметрь в данном случае полностью заметна и под эту ситуацию тоже не попадает.

«Незаметные повреждения» это или из теории заговоров или «мы купили на савеле какието диски».

у дисков есть ECC, который работает полностью автономно и, если только не совсём всё плохо, всегда успешно исправляет такие штуки.

Нет, не всегда :)

у дисков есть ECC, который работает полностью автономно и, если только не совсём всё плохо, всегда успешно исправляет такие штуки.

Нет, не всегда :)

да-да так и будет (с) :)

Почитай про SCSI/SAS и FC диски с размером сектора 520 и 528 байтов, в отличие от старого 512, и для чего это было сделано :)

Интересно. Что же, на поверхность данные реально записываются «как есть», в сыром виде? Всю жизнь думал, что и внутри старого 512 сектора – тоже какой-нибудь код Рида-Соломона, и что так было всегда.

А вы зачем мне мне это написали? Я с вами согласен :)