Question Comment réduire la vitesse de liaison SATA du lecteur dans CentOS?


Comment faire en sorte que CentOS exécute des disques SATA à 3 Gb / s au démarrage?

Contexte:

Je rencontre un problème avec une carte mère qui prétend prendre en charge des vitesses de transfert SATA de 6 Gb / s, mais lorsque vous utilisez 4 lecteurs sur celle-ci, dans un logiciel RAID 10 avec une E / S de disque lourde, certaines liaisons SATA commencent à générer des erreurs de noyau, par exemple. ata1.00: failed command: WRITE FPDMA QUEUED. Mais il s’agit d’un lecteur différent à chaque fois, pas toujours ata1, et l’exécution de tests étendus sur chaque disque ne produit aucune erreur.

Lorsque les erreurs se produisent, le noyau / système d’exploitation (CentOS 6.2) réinitialise éventuellement le lien à plusieurs reprises. Lorsqu'il continue à échouer, il modifie la vitesse de la liaison en 3Gb / s. Une fois que cela se produit, les erreurs s’arrêtent pour ce lecteur pour le reste de la session.

Ce que j'aimerais faire, c'est dire au système d'exploitation de régler les liaisons SATA sur 3Gb / s pour démarrer au démarrage, car je ne pense pas que le bus SATA de la carte mère puisse gérer les 4 disques à 6Gb / s. Je ne pouvais pas trouver une option dans le BIOS de la carte mère pour changer la vitesse de liaison.

Des questions:

  1. Comment pourrais-je m'y prendre? c'est à dire. un fichier de configuration?

  2. Cela peut-il être fait pendant que le système est en cours d'exécution avec la matrice RAID assemblée et la partition racine montée ou dois-je démarrer à partir d'un CD de secours?

  3. Cela entraînera-t-il une perte de données? J'ai des sauvegardes bien sûr, mais la réinstallation / restauration représente plusieurs heures de travail que j'aimerais éviter si possible.


5
2018-06-19 22:33


origine




Réponses:


Malheureusement, il n’existe rien au moment de l’exécution (il existe / sys / class / ata_link qui contient des informations en lecture seule).

Cependant, au démarrage, il semble que vous puissiez configurer des paramètres pour imposer les valeurs souhaitées. La documentation pour ceci est ici: http://www.kernel.org/doc/Documentation/kernel-parameters.txt

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.

De prime abord, le paramètre du noyau libata.force = 3.0G devrait fonctionner.

En ce qui concerne la perte de données, probablement pas - mais franchement, étant donné que les fournisseurs de SATA n’ont clairement pas respecté correctement la spécification SATA (ou son buggy ou quoi que ce soit), alors qui sait.


5
2018-06-19 22:51



Merci pour votre réponse, je suis toujours un peu confus, où libata.force=3.0G aller? Et est le G censé être à la fin? - Nick
+1 pour la référence utile, mais la réponse n'était pas complète. - Nick


La réponse de MIfe était ici un bon indice (+1 pour la référence utile), mais pas complètement complète.

Pour définir les liaisons SATA sur 3Gb / s:

  1. modifier /boot/grub/grub.conf

  2. Trouvez la ligne qui commence par kernel. Sur le mien, c'était:

    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. Ajouter libata.force=3.0 dans cette ligne de noyau quelque part.

  4. Redémarrer

Après avoir effectué ce qui précède, je suis maintenant capable d’exécuter des opérations intensives en E / S, telles que la copie d’images de machine virtuelle d’une partie du disque à une autre sans plus en obtenir. WRITE FPDMA QUEUED les erreurs.


4
2018-06-20 06:47





Comme quelqu'un pourrait trébucher sur cette question juste comme je viens de le faire: Une solution très simple au problème pourrait consister à échanger le câble SATA. J'ai transféré un disque SSD de 2014 dans un système 2018 et utilisé l'ancien câble non blindé pour le connecter. J'ai exactement les erreurs et les problèmes décrits ici. Ils étaient tous complètement partis après que j'ai échangé le câble contre un autre blindé moderne.

Je pouvais même voir dans /var/log/syslog que le contrôleur SATA a tenté de réinitialiser la vitesse de la liaison à 1,5 Go et n’a toujours pas réussi à communiquer avec le disque. Sans aucun changement de configuration, le nouveau câble a fonctionné de manière absolument parfaite.

Par conséquent, avant d'appliquer certaines modifications de configuration, vous pouvez simplement essayer une approche de solution simple.


1
2017-07-23 11:11





Le rétrograder à 3 Gbps peut ne pas être possible de cette façon, mais il devrait être possible de rétrograder les liens à 1,5 Gbps. Sauf si vous avez des disques durs 10k ou SSD, ils ne pourront de toute façon pas saturer le lien 150Mo / s ...

La plupart des disques durs peuvent être contraints de négocier une vitesse inférieure à l'aide de cavaliers. Google pour "Sata 1 jumpers votre modèle d'entraînement"


0
2018-06-19 23:41



Il semble que le système d'exploitation ou le noyau rétrograde la vitesse de 6 à 3 lorsqu'il détecte des erreurs d'écriture. Il doit donc exister un paramètre de niveau système. La question qui se pose est de savoir comment définir ce paramètre de sorte qu'il commence à 3, sans avoir à revenir à 3 lorsque des erreurs se produisent. - Nick