Como eu direciono um driver específico para modificação de parâmetro do kernel libata?

Question

Estou executando uma instalação de 22 discos, 19 deles em uma matriz ZFS, 15 dos quais são apoiados por três multiplicadores de portas conectados a controladores SATA controlados pelo módulo sata_sil24 . Ao executar a velocidade máxima (SATA2, 3 Gbps), a operação é bem peculiar. Erros de leitura simples lançam um multiplicador de porta inteiro em espasmos por um longo tempo, às vezes com resultados bastante ruins. A inicialização com o parâmetro de kernel libata.force=1.5G para forçar os controladores SATA em velocidades "herdadas" corrige completamente todos os problemas com os multiplicadores de porta. A coisa é, meu pool ZFS é apoiado por um SSD de cache rápido no meu controlador ICH10R. Outro SSD neste mesmo controlador mantém o sistema.

Fazer libata.force=1.5G reduz imediatamente cerca de 100 MB / s da taxa de transferência dos meus SSDs. Para o drive raiz, isso não é grande coisa, mas para o SSD do cache ZFS, é. Ele efetivamente torna o zpool inteiro mais lento para transferências sustentadas do que teria sido sem a unidade de cache. Acesso aleatório e pesquisas de árvore de fs, claro, ainda se beneficiam. Listando as opções do módulo para sata_sil24 , nenhuma opção existe.

Como passar o parâmetro libata.force=1.5G para apenas os três controladores SATA suportados pelo módulo sata_sil24 ?

    

Answer 1

Ah! Eu descobri!

No link , ele afirma

    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.

Então, a parte complicada é descobrir qual porta X e o dispositivo Y (dmesg ataX.YY) é qual controlador e unidade. Eu acho - essa notação corresponde a PORT [.DEVICE], mas há também a notação W: X: Y: Z. Eu estou supondo que ataX.YY:)

Felizmente, eu fiz este mapeamento manualmente na semana passada (tentando identificar uma unidade que estava lançando espasmos e reiniciando um controlador host), então eu já tenho uma lista exaustiva :) Eu não consegui encontrar nenhum lugar que os mapeamentos do sdX para ataX.Y ou W: X: Y: Z onde listado, então acabei simplesmente arrancando cabos SATA e observando quais mensagens ataX.YY apareciam em / var / log / messages;)

Então, na minha configuração, parece que preciso fazer

libata.force=1:1.5G,2:1.5G,3:1.5G

Vou ter que tentar isso assim que terminar meu scrub ZFS e relatar :) Incrível! Espero que isso ajude alguém:)