LINUX.ORG.RU
решено ФорумAdmin

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

 ,


0

3

От безысходности пишу сюда. Не знаю в чем проблема.

Стоит домашний сервер, 4 hdd диска в raid6 через mdadm. Все настройки кешей, флаги дефолтные.

Раз в месяц запускается scrubbing и где-то на половине прогресса i/o падает в ноль. Но сервер продолжает работать если программа осталась в озу. Т.е можно зайти по ssh, что-то делать пока это не связано с обращением к массиву.

Помогает только hard reset. Логи чистые как слеза младенца. Ошибок нет вообще. Стоит также smartctl, все чисто. Диски каждый день проходят быструю проверку.

Диски охлаждаются хорошо, стоят в корзине для дисков с обдувом, под нагрузкой темпа не выше 48 градусов (без ~40).

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

Перемещено hobbit из general


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

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

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

pv /dev/sda > /dev/null

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

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

AEP ★★★★★
()
Ответ на: комментарий от AEP

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

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

token_polyak ★★★★
()
Ответ на: комментарий от AEP

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

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

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

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

ginky
() автор топика

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

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

ginky
() автор топика
Ответ на: комментарий от ginky

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

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

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 2)
Ответ на: комментарий от Dimez

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

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

ginky
() автор топика
Ответ на: комментарий от ginky

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

Minona ★★☆
()
Ответ на: комментарий от Minona

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

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

vbr ★★★
()
Ответ на: комментарий от vbr

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

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

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

Dimez ★★★★★
()

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

ginky
() автор топика
Ответ на: комментарий от firkax

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

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

anc ★★★★★
()
Ответ на: комментарий от anc

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

anc ★★★★★
()
Ответ на: комментарий от Dimez

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

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

firkax ★★★★★
()
Ответ на: комментарий от anc

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

firkax ★★★★★
()
Ответ на: комментарий от Dimez

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

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

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

anc ★★★★★
()
Ответ на: комментарий от Dimez

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

i586 ★★★★★
()