Como reduzir a velocidade do link SATA do drive no CentOS?

Question

Como faço para o CentOS executar unidades SATA em 3Gb / s durante a inicialização?

Histórico:

Estou tendo um problema com uma placa-mãe que suporta velocidades de transferência SATA de 6 Gb / s, mas ao usar 4 unidades nela, em um software RAID 10 com disco rígido IO, alguns dos links SATA começam a gerar erros do kernel , ou seja. %código%. Mas é uma unidade diferente a cada vez, nem sempre ata1, e a execução do teste estendido em cada disco individualmente não produz erros.

Quando os erros ocorrem, o Kernel / OS (CentOS 6.2) eventualmente redefine o link várias vezes, e quando ele continua a falhar, ele altera a velocidade do link para 3Gb / s. Quando isso acontece, os erros param para essa unidade pelo restante da sessão.

O que eu gostaria de fazer é dizer ao sistema operacional para definir os links SATA para 3Gb / s para iniciar na inicialização, já que não acho que o barramento SATA da placa-mãe pode lidar com todos os 4 discos a 6Gb / s. Não consegui encontrar uma opção no BIOS da placa-mãe para alterar a velocidade do link.

Perguntas:

1. Como eu faria isso? ie. um arquivo de configuração?

2. Isso pode ser feito enquanto o sistema está sendo executado com a matriz RAID montada e a partição raiz montada, ou eu preciso inicializar a partir de um CD de recuperação?

3. Isso resultará em perda de dados? Eu tenho backups, é claro, mas reinstalar / restaurar é várias horas de trabalho que eu gostaria de evitar, se possível.

Answer 1

Infelizmente, não há nada no tempo de execução (existe / sys / class / ata_link que contém informações somente de leitura).

No entanto, na inicialização, parece que você pode configurar os parâmetros que forçam os valores desejados. A documentação para isso está aqui: link

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.

Da aparência das coisas, o parâmetro do kernel libata.force = 3.0G deve funcionar ..

Com relação à perda de dados, provavelmente não - mas francamente, já que os fornecedores da SATA claramente não honraram as especificações da SATA corretamente (ou seu buggy ou qualquer outro), então quem sabe.

    

Answer 2

A resposta de MIfe aqui foi uma boa pista (+1 para referência útil), mas não totalmente completa.

Para definir os links SATA para 3Gb / s:

1. Edite /boot/grub/grub.conf

2. Encontre a linha que começa com kernel . No meu, foi:

   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...

3. Adicione libata.force=3.0 nessa linha do kernel em algum lugar.

4. Reinicializar

Depois de fazer o acima, agora posso executar operações intensivas de E / S, como copiar imagens de máquinas virtuais de uma parte do disco para outra, sem receber mais erros WRITE FPDMA QUEUED .

    

Answer 3

Como alguém pode tropeçar nessa questão como acabei de fazer: Uma solução muito simples para o problema poderia ser trocar o cabo SATA. Mudei um SSD de 2014 para um sistema 2018-ish e usei o antigo cabo não blindado para conectá-lo. Eu tenho exatamente os erros e problemas descritos aqui. Eles foram todos completamente depois que eu troquei o cabo para um moderno blindado.

Eu poderia até ver em /var/log/syslog que o controlador SATA tentou redefinir a velocidade do link para 1,5 GB e ainda não conseguiu se comunicar com o disco. Sem qualquer alteração de configuração, funcionou perfeitamente com o novo cabo conectado.

Portanto, antes de aplicar algumas alterações de configuração, você pode tentar uma abordagem de solução simples.

    

Answer 4

Fazer downgrade para 3Gbps pode não ser possível dessa forma, mas deve ser possível fazer o downgrade dos links para 1.5Gbps. A menos que você tenha unidades de 10k ou que sejam SSDs, elas não conseguirão saturar o link de 150MB / s de qualquer maneira ...

A maioria dos discos rígidos pode ser forçada a negociar menor velocidade usando jumpers. Google para "Sata 1 jumpers seu modelo de unidade "