Почему mdadm не может справиться с «почти неисправным» диском?
Много раз в своей карьере я сталкивался с наборами mdadm RAID (RAID1+0, 5, 6 и т. д.) в различных средах (например, CentOS/Debian, Synology/QNAP NAS). ), которые, по-видимому, просто не в состоянии справиться с неисправным диском. Это диск, который не полностью мертв, но имеет десятки тысяч сбойных секторов и просто не может обрабатывать ввод-вывод. Но он не совсем мертв, он все еще работает. Журнал ядра обычно полон ошибок UNC.
Иногда SMART идентифицирует диск как неисправный, в других случаях никаких других симптомов, кроме медленного ввода-вывода, не наблюдается.
Медленный ввод-вывод фактически приводит к зависанию всей системы. Подключение по ssh занимает вечность, веб-интерфейс (если это NAS) обычно перестает работать. Выполнение команд через ssh также занимает вечность. То есть до тех пор, пока я не отключу / намеренно не «выведу» диск из массива, тогда все вернется к «нормальному» - это настолько нормально, насколько это может быть с деградировавшим массивом.
Мне просто интересно, если чтение/запись диска занимает так много времени, почему бы просто не выбить его из массива, оставить сообщение в журнале и продолжить? Кажется, что вся система останавливается из-за того, что один диск немного неисправен, полностью сводит на нет одно из основных преимуществ использования RAID (отказоустойчивость - способность продолжать работу в случае сбоя диска). Я могу понять, что в сценарии с одним диском (например, в вашей системе подключен только один диск SATA, и он не может правильно выполнять чтение/запись) это катастрофа, но в наборе RAID (особенно отказоустойчивых «личностей») это кажется не только раздражающим, но и противоречащим здравому смыслу.
Есть ли очень веская причина, по которой mdadm по умолчанию ведет себя так, что он выводит из строя коробку до тех пор, пока кто-нибудь не подключится и не починит ее вручную?
Основная проблема заключается в том, что неисправный диск SATA может иногда заморозить всю шину на время внутренней процедуры восстановления после ошибки. По этой причине следует использовать диски с поддержкой TLER-только в RAID-массивах (и желательно модели корпоративного-класса).
Диски SAS меньше страдают от этой проблемы, но и не полностью свободны от нее.
У меня были ситуации, когда диск не работал, но каким-то образом выводил из строя контроллер.
Исторически это было возможно с PATA, где главный и подчиненный диски были на одном кабеле, и сбой одного диска мог помешать доступу к другому -исправному диску. Удаление неисправного диска может восстановить доступ к оставшемуся диску, или может потребоваться перезагрузка-питания, но рейд может выйти из строя, после чего можно будет начать восстановление.
SATA менее уязвим для этого, но контроллер все еще может быть затронут. Исходя из моего опыта программных рейдов, я обнаружил больше кровавых внутренностей, которые были бы скрыты более причудливым специализированным рейд-контроллером.
Я не сталкивался с этим с SAS или NVME, но SAS часто означает аппаратные RAID-контроллеры, которые имеют больше дисков,-обрабатывающих интеллект внутри.
В дополнение к сказанному хочу добавить свою копейку, но это важное соображение.
Что делает диск , когда сектор читается медленно?
Предположительно приводы, предназначенные для работы в одиночку, т.е. г. типичные «настольные» диски, предполагают, что нет другого способа получить данные, хранящиеся в этом поврежденном секторе. Они будут пытаться получить данные любой ценой, повторяя снова и снова в течение длительного периода времени. Конечно, они также пометят этот сектор как неисправный, поэтому они переназначат его в следующий раз, когда вы будете писать в него, но вы должны написать для этого. Пока не перепишешь, они будут задыхаться каждый раз, когда ты будешь читать оттуда. В настройках RAID это означает, что для RAID диск все еще работает, и нет причин его отключать, но для приложений массив будет замедляться до минимума.
С другой стороны, «корпоративные» диски, особенно «фирменные», часто предполагают, что они всегда используются в настройках RAID. «Фирменный» контроллер, увидев «фирменный» диск, может даже уведомить свою прошивку о наличии RAID. Таким образом, накопитель остановится раньше и сообщит об ошибке ввода-вывода, даже если можно было сделать еще несколько попыток и прочитать сектор. Тогда у контроллера есть шанс ответить быстрее, зеркально отразив инструкцию чтения на одноуровневом диске (и удалив неисправную из массива). Когда вы вытащите и внимательно изучите/протестируете этот выбитый диск, вы не обнаружите явных проблем — он просто замедлился на мгновение, и этого было достаточно, чтобы прекратить его использование, согласно логике контроллера.
Я предполагаю, что это может быть единственным различием между «настольными» дисками и «фирменными»/«корпоративными» дисками NL-SAS и SATA.Вероятно, поэтому вы платите в три раза больше, когда покупаете диск «HPE», который на самом деле был произведен Toshiba, по сравнению с покупкой диска под маркой «Toshiba»-.
Однако некоторые приводы поддерживают некоторые общие элементы управления этим. Он называется SCT ERC, что означает SMART Command Transport Error Recovery Control . Вот как это выглядит вsmartctl:
не поддерживается
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
поддерживается
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
Если вам повезет, вы можете управлять этой функцией с помощью smartctl. Вы можете получить или установить два тайм-аута: как долго пытаться-читать и сколько времени пытаться-записывать :
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
, что означает:120 десятых секунды на повторную попытку чтения; 60 десятых секунды на повторную попытку записи. Ноль означает «повторяй, пока не умрешь». Различные диски имеют разные настройки по умолчанию для этого.
Таким образом, если вы используете только диск "RAID edition", лучше установить для тайм-аутов ERC нулевое значение, иначе вы можете потерять данные. С другой стороны, если вы используете диски в RAID, лучше установить какое-нибудь разумное низкое значение, отличное от -нуля.
Источник amarao @ Habrahabr, на русском .
П.С. И заметка о SAS. Используйте sdparm, он поддерживает больше элементов управления этим.