failed command: READ FPDMA QUEUED

Столкнулся с неприятной ошибкой на новом сервере HP Microserver G8. Он был приобретен под файловый сервер, к нему были куплены 2 жестких диска WD RED 4 Tb, сделан mdadm raid 1 и установлена система CentOS 7. После ввода сервера в эксплуатацию в логах появились ошибки.

HP Microserver G8 и диски 4 Тб

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

Сейчас считаю наиболее удобным и функциональным именно серию G8, так как у нее есть интерфейс для удаленного управления ILO. И это в сервере за 18000 р. с самым слабым процессором, которого тем не менее за глаза хватает для обычного файлового сервера.

По документации данный сервер поддерживает максимум диски 3 Tb. Но по отзывам в интернете я увидел, что люди без проблем ставят диски большего объема и нормально ими пользуются. Решил тоже попробовать купить для начала 2 диска по 4 Tb и попробовать их в работе.

Во время установки и настройки CentOS 7 никаких проблем не возникло. Я спокойно настроил samba с интеграцией в AD, разместил все это на raid1 mdadm. Подергал диски, убедился, что сервер нормально запускается при выходе из строя любого из дисков. Перенес рабочие данные со старого сервера и запустил новый сервер в эксплуатацию.

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

Ошибки в работе сервера

Теперь, собственно, что у меня случилось. Через пару дней после начала работы сервера, стал замечать в логах следующие ошибки.

Oct 12 10:42:52 xs-design kernel: ata1.00: exception Emask 0x0 SAct 0xf80 SErr 0x40000 action 0x6 frozen
Oct 12 10:42:52 xs-design kernel: ata1: SError: { CommWake }
Oct 12 10:42:52 xs-design kernel: ata1.00: failed command: READ FPDMA QUEUED
Oct 12 10:42:52 xs-design kernel: ata1.00: cmd 60/00:38:60:0a:27/01:00:5c:00:00/40 tag 7 ncq 131072 in#012         res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 12 10:42:52 xs-design kernel: ata1.00: status: { DRDY }
Oct 12 10:42:52 xs-design kernel: ata1.00: failed command: READ FPDMA QUEUED
Oct 12 10:42:52 xs-design kernel: ata1.00: cmd 60/00:40:60:0b:27/01:00:5c:00:00/40 tag 8 ncq 131072 in#012         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 12 10:42:52 xs-design kernel: ata1.00: status: { DRDY }
Oct 12 10:42:52 xs-design kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Oct 12 10:42:52 xs-design kernel: ata1.00: cmd 61/01:48:10:28:20/00:00:00:00:00/40 tag 9 ncq 512 out#012         res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 12 10:42:52 xs-design kernel: ata1.00: status: { DRDY }
Oct 12 10:42:52 xs-design kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Oct 12 10:42:52 xs-design kernel: ata1.00: cmd 61/07:50:18:a8:a0/00:00:02:00:00/40 tag 10 ncq 3584 out#012         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 12 10:42:52 xs-design kernel: ata1.00: status: { DRDY }
Oct 12 10:42:52 xs-design kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Oct 12 10:42:52 xs-design kernel: ata1.00: cmd 61/08:58:d0:43:4d/00:00:ea:00:00/40 tag 11 ncq 4096 out#012         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 12 10:42:52 xs-design kernel: ata1.00: status: { DRDY }
Oct 12 10:42:52 xs-design kernel: ata1: hard resetting link
Oct 12 10:42:53 xs-design kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct 12 10:42:53 xs-design kernel: ata1.00: configured for UDMA/133
Oct 12 10:42:53 xs-design kernel: ata1: EH complete

Ошибки возникали не часто, примерно 2-3 раза в день. Что удивительно, я тестировал сервер нагрузками, генерил дисковые операции, переносил порядка 3-х Тб информации со старого сервера. Диски работали нормально, ошибок не было.

Я понял, что это не ошибки самих дисков, так как в логах периодически были ошибки как ata1, так и ata2. Вероятность того, что я купил 2 неисправных диска была не очень большая, к тому же к самим данным не было проблем с доступом. Внешне никаких проблем с сервером не было, он нормально работал. Тем не менее, с ошибками нужно было разбираться.

Я начал гуглить и приуныл от перспектив, которые передо мной вырисовывались. Эту ошибку могут вызывать множество факторов. Обратить внимание и проработать нужно было следующие варианты:

1. HP Microserver G8 не поддерживает 4 Tb диски, поэтому периодически возникают проблемы.
2. Есть проблемы с проводами или разъемами в самом сервере, через которые подключены диски.
3. У CentOS 7 достаточно старое ядро - 3.10. Есть информация о том, что решением данной проблемы может быть обновление до 4-й версии ядра.
4. Диски WD RED имеют включенный режим энергосбережения, который приводит к засыпанию дисков после некоторого периода бездействия. При выходе из засыпания могут появляться указанные выше ошибки.
5. По какой-то причине некорректно работает технология NCQ, которая фигурирует в текстах ошибок.

Я решил действовать от простого к сложному. Ранее я уже сталкивался с проблемой в дисках WD. Суть ее вот в чем. В некоторых прошивках дисков стоит режим засыпания через 8 секунд неактивности, после которого диск паркует головки. При работе дисков с этой прошивкой в linux возникает такая ситуация, что диски постоянно то засыпают, то просыпаются. Это особенность linux, который не пишет непрерывно на диск, а накапливает данные в буфер, а потом записывает на диск примерно с таким же интервалом.

Ранее мне приходилось выводить из работы сервера с дисками WD, в которых накапливалось по информации из параметра Load Cycle Count в SMART до 1 000 000 паркового головок, что приводит к поломкам дисков. Считается, что современные диски рассчитаны на 300 000 - 500 000 парковок. Частые парковки головок изнашивают механику диска, снижая его надежность.

Если у вас есть диски WD серии GREEN или RED, рекомендую обратить внимание на описанную особенность. Проверить, какой интервал для засыпания диска установлен в его прошивке, можно с помощью консольной утилиты для linux - idle3-tools. Я проверил свои диски. Они засыпали после 13 секунд неактивности диска. Я полностью отключил этот режим, диски все равно работают 7/24, сбережение электроэнергии меня не интересует.

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

Далее я решил обновить ядро в CentOS 7 до 4-й версии. В принципе, ничего сложного в этом нет. Руководств в интернете достаточно. Для начала сделал все на тестовой системе. Ядро обновил без проблем, но все же не рискнул это делать на рабочем сервере. Раньше я никогда не изменял дефолтное ядро в CentOS, я не уверен, что это не приведет к каким-то проблемам в будущем. Сервер этот достаточно важен и должен работать надежно и стабильно. В общем, не рискнул. Решил оставить этот вариант на самый последний момент.

Далее нужно было было проверять провода и разъемы. Если проблемы с ними, то никакие остальные действия не помогут. Это было сделать очень затруднительно. Сервер постоянно в работе. Чтобы его проверить, нужно было останавливать и разбирать в нерабочее время - поздно вечером. Я предпочитаю это время проводить с семьей, поэтому тоже отложил на самый крайний случай, если ничего другого не поможет.

Дальше я решил отключить NCQ (Native Command Queuing). Что это такое прочитайте сами, не буду останавливаться на этом. Отключаем NCQ в linux так:

echo 1 > /sys/block/sda/device/queue_depth
echo 1 > /sys/block/sdb/device/queue_depth

Проверить, какое значение установлено сейчас можно так:

cat /sys/block/sda/device/queue_depth

Все, что не равно 1 означает, что ncq включен и работает. Подождал несколько дней и к своей радости обнаружил, что ошибок больше нет. На производительности дисковой подсистемы особо не сказалось отключение этой очереди команд. Но, правда, и сервер работает без нагрузки. С ним работают несколько человек, причем не очень интенсивно, так что меня устроило текущее положение дел.

Заключение

Я не до конца понял, в чем в итоге была проблема. Если бы у меня не было еще таких серверов, но только с дисками меньшего объема, я бы решил, что HP Microserver G8 не поддерживает полностью CentOS. Но у меня без проблем работают такие же сервера, только с дисками 3 Tb. Специально их проверил, никаких ошибок не было.

Так что скорее всего проблема все же именно в дисках на 4 Tb. Лично я не посоветую никому покупать их в этот сервер. Оно может и будет работать, но лично я в продакшене рисковать не люблю, и использую всегда максимально надежные решения. 4 диска по 3 Tb в raid1 или raid10 это 6 Tb данных. Для такого процессора и сервера это нормальный объем. Для больших объемов можно использовать более производительные сервера.

Помогла статья? Подписывайся на telegram канал автора