Как заставить CentOS запускать диски SATA со скоростью 3 Гбит / с при загрузке?
Задний план:
У меня проблема с материнской платой, которая утверждает, что поддерживает скорость передачи SATA 6 Гбит / с, но при использовании на ней 4 дисков в программном массиве RAID 10 с тяжелым дисковым вводом-выводом некоторые ссылки SATA начинают выдавать ошибки ядра, т. Е. ata1.00: failed command: WRITE FPDMA QUEUED
. Но каждый раз это другой диск, не всегда ata1, и запуск расширенного теста на каждом диске по отдельности не вызывает ошибок.
Когда возникают ошибки, ядро / ОС (CentOS 6.2) в конечном итоге несколько раз сбрасывает соединение, а когда он продолжает давать сбой, оно изменяет скорость соединения на 3 Гбит / с. Как только это произойдет, ошибки прекратятся для этого диска на оставшуюся часть сеанса.
Я бы хотел сказать ОС, чтобы она установила для каналов SATA значение 3 Гбит / с для начала при загрузке, поскольку я не думаю, что шина SATA материнской платы может обрабатывать все 4 диска со скоростью 6 Гбит / с. Я не смог найти в BIOS материнской платы возможность изменить скорость соединения.
Вопросы:
Как я могу это сделать? т.е. файл конфигурации?
Можно ли это сделать, пока система работает с собранным массивом RAID и смонтированным корневым разделом, или мне нужно загружаться с аварийного компакт-диска?
Приведет ли это к потере данных? У меня, конечно, есть резервные копии, но переустановка / восстановление - это несколько часов работы, которых я бы по возможности избегал.
К сожалению, во время выполнения ничего нет (есть / sys / class / ata_link, который содержит информацию только для чтения).
Однако при загрузке кажется, что вы можете установить параметры принудительного значения, которые вы хотите. Документация для этого находится здесь: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
Specifically
libata.force= [LIBATA] Force configurations. The format is comma
separated list of "[ID:]VAL" where ID is
PORT[.DEVICE]. PORT and DEVICE are decimal numbers
matching port, link or device. Basically, it matches
the ATA ID string printed on console by libata. If
the whole ID part is omitted, the last PORT and DEVICE
values are used. If ID hasn't been specified yet, the
configuration applies to all ports, links and devices.
If only DEVICE is omitted, the parameter applies to
the port and all links and devices behind it. DEVICE
number of 0 either selects the first device or the
first fan-out link behind PMP device. It does not
select the host link. DEVICE number of 15 selects the
host link and device attached to it.
The VAL specifies the configuration to force. As long
as there's no ambiguity shortcut notation is allowed.
For example, both 1.5 and 1.5G would work for 1.5Gbps.
The following configurations can be forced.
* Cable type: 40c, 80c, short40c, unk, ign or sata.
Any ID with matching PORT is used.
* SATA link speed limit: 1.5Gbps or 3.0Gbps.
* Transfer mode: pio[0-7], mwdma[0-4] and udma[0-7].
udma[/][16,25,33,44,66,100,133] notation is also
allowed.
* [no]ncq: Turn on or off NCQ.
* nohrst, nosrst, norst: suppress hard, soft
and both resets.
* dump_id: dump IDENTIFY data.
If there are multiple matching configurations changing
the same attribute, the last one is used.
Судя по всему, параметр ядра libata.force = 3.0G должен работать ..
Что касается потери данных, вероятно, нет - но, честно говоря, поскольку поставщики SATA явно не соблюдали спецификацию SATA должным образом (или ее ошибки, или что-то еще), тогда кто знает.
Ответ MIfe здесь был хорошей подсказкой (+1 за полезную ссылку), но не полностью.
Чтобы установить для каналов SATA скорость 3 Гбит / с:
редактировать /boot/grub/grub.conf
Найдите строку, которая начинается с kernel
. По моему это было:
kernel /vmlinuz-2.6.32-220.17.1.el6.x86_64 ro root=/dev/mapper/vg_lago-host rd_NO_LUKS LANG=en_US.UTF-8...
Добавить libata.force=3.0
в эту строку ядра где-нибудь.
перезагрузка
После выполнения вышеизложенного я теперь могу выполнять операции с интенсивным вводом-выводом, такие как копирование образов виртуальных машин с одной части диска на другую, не получая больше WRITE FPDMA QUEUED
ошибки.
Кто-то может натолкнуться на этот вопрос, как и я: очень простым решением проблемы может быть замена кабеля SATA. Я переместил SSD из 2014 года в систему 2018 года и использовал старый неэкранированный кабель для его подключения. Я получил именно те ошибки и проблемы, которые описаны здесь. Все они исчезли полностью после того, как я заменил кабель на современный экранированный.
Я даже мог видеть в /var/log/syslog
что контроллер SATA попытался сбросить скорость соединения до 1,5 ГБ, но по-прежнему не смог связаться с диском. Без каких-либо изменений конфигурации он работал абсолютно безупречно с подключенным новым кабелем.
Итак, прежде чем вносить некоторые изменения в конфигурацию, вы можете просто попробовать простое решение.
Понижение скорости до 3 Гбит / с таким образом может оказаться невозможным, но должна быть возможность понизить скорость до 1,5 Гбит / с. Если у вас нет накопителей на 10 КБ или это SSD, они все равно не смогут заполнить канал 150 МБ / с ...
Большинство жестких дисков можно заставить переключиться на более низкую скорость с помощью перемычек. Google по запросу "Джамперы Sata 1" ваша модель привода"