неуспешная команда: ЗАПИСЬ FPDMA В ОЧЕРЕДИ – причина медленной работы сервера?

Вопрос или проблема

Linux NFS файловый сервер работает медленно последние пару дней (на основании субъективных отчетов пользователей). Я проверил journalctl и не увидел никаких соответствующих ошибок.

Однако, когда я подключил монитор, меня встретил экран, заполненный этими ошибками:
“`
failed command: WRITE FPDMA QUEUED
“`
Вот скриншот:

Что я могу предпринять дальше? Стоит ли просто заменить диск?

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

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

Если ошибка вернется после перезагрузки, я бы подключил этот диск к другому SATA порту, и, если необходимо, подключил бы какой-то другой диск к этому порту. Если ошибка все еще на том же порту, то проблема с контроллером.

Но если ошибка “переместится” на новый порт, то это либо кабель, либо диск. На этом этапе я бы заменил SATA кабель. Если ошибка исчезнет, значит, проблема была в плохом кабеле. Если ошибка все еще присутствует, значит, это диск.

Еще одно, что вы можете попробовать (что работает удаленно), это запустить `smartctl -a`, чтобы увидеть, сообщает ли диск о каких-либо ошибках, а также, возможно, `smartctl -t short`, чтобы провести самотестирование.

В моем случае это показало, что сбои `WRITE FPDMA QUEUED` были вызваны ошибкой `ICRC` (интерфейс CRC), что означает, что данные были повреждены между диском и контроллером, так что диск в порядке, и проблема либо в SATA кабеле, либо в электронике на одном из концов, куда подключен SATA кабель.

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

У меня такая же проблема (`failed command: WRITE FPDMA QUEUED`) на диске Apacer AS350 1TB с более старым ноутбуком i7 (т.е. на чипсете Intel).

Я нашел это на обсуждении ошибки ядра:
[ссылка](https://bugzilla.kernel.org/show_bug.cgi?id=203475#c15)

Я полагаю, что если вы видите сообщения “WRITE FPDMA QUEUED”, проблема связана с NCQ в целом, и да, вам следует попробовать отключить это для устройства. Но если вы видите “SEND FPDMA QUEUED”, как в первоначальном посте, то вы могли бы обойтись отключением только очереди TRIM.

Добавление `libata.force=1:3.0G,1:noncq` “решило” проблему для меня, но, конечно, это замедлило диск. Я думаю, часть `1:3.0G` неважна.

Обновление прошивки на SSD может решить такие проблемы, но Apacer предоставляет только обновления прошивки на Windows, которые я не могу легко применить и протестировать.

Ответ или решение

Проблема с замедлением сервера: Причины и шаги по устранению ошибок "failed command: WRITE FPDMA QUEUED"

Недавние жалобы пользователей о медленной работе файлового сервера на Linux через NFS могут быть связаны с ошибками, отображающимися в системе. Одной из таких ошибок является "failed command: WRITE FPDMA QUEUED", которая указывает на проблемы с передачей данных между диском и контроллером.

Причины возникновения ошибки

Ошибка "WRITE FPDMA QUEUED" сама по себе подразумевает, что запрос записи данных был поставлен в очередь, однако произошел сбой в процессе. Потенциальные причины этой ошибки могут включать:

1. Проблемы с самим диском: Это может быть результатом физического износа, неправильной работы или неисправности устройства.
2. Проблемы с соединениями: Поврежденные или неправильно установленные SATA-кабели могут вызвать потерю данных между диском и контроллером.
3. Неисправности контроллера: Если контроллер SATA имеет сбои или несовместимости, это также может приводить к подобным ошибкам.
4. Ошибки интерфейса CRC (Interface CRC errors): Это указывает на то, что данные были повреждены во время передачи данных.

Рекомендованные действия

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

2. Проверка соединений:

   • После перезагрузки проверьте, если ошибка повторяется, отключите диск от текущего SATA-порта и подключите его к другому порту. Этот шаг поможет определить, связан ли сбой с конкретным портом на контроллере.
   • Если после перемещения ошибки остаются на новом порту, вероятнее всего, проблема заключается в контроллере. В противном случае переходите к следующему шагу.

3. Замена SATA-кабеля: Если ошибка "движется" на новый порт, замените SATA-кабель. Это простая и недорогая мера, которая может решить проблему, если изначальная причина правдива в поврежденной проводке.

4. Проверка состояния диска с помощью SMART:

   • Используйте команду smartctl -a /dev/sdX для получения информации о состоянии диска.
   • Выполните команду smartctl -t short /dev/sdX для выполнения краткосрочного теста диска. Это может помочь выявить проблемы на уровне диска, такие как сбои, которые могли бы вызвать ошибки записи.

5. Отключение NCQ: Некоторые пользователи, сталкивающиеся с подобной проблемой, сообщают о том, что отключение функции NCQ (Native Command Queuing) значительно снижает количество ошибок. Это можно сделать с помощью параметра загрузки ядра, например, libata.force=1:noncq. Однако стоит учитывать, что это может снизить производительность диска.

6. Обновление прошивки: Если проблема не устраняется, следует проверить наличие обновлений прошивки для вашего жесткого диска. Некоторые производители предлагают специфические исправления, которые могут устранить проблемы с совместимостью.

Заключение

Ошибки, такие как "failed command: WRITE FPDMA QUEUED", могут существенно влиять на производительность вашего файлового сервера и вызывать замедление его работы. Следуя приведенным выше шагам, вы сможете определить конкретную причину проблемы и минимизировать её влияние. Замена оборудования является крайней мерой; прежде чем принимать такое решение, важно тщательно диагностировать проблему с использованием доступных инструментов и методов.