Pourquoi les erreurs de vérification NAS suivent-elles un même port de contrôleur sur différents disques ?

Les erreurs de vérification qui suivent un port de contrôleur d’un disque à l’autre indiquent généralement un problème sur le chemin commun plutôt que sur le support d’enregistrement des disques.

Une vérification lit un vaste ensemble de blocs et peut révéler des défaillances qu’un accès quotidien ordinaire n’atteint jamais. Si différents disques connus comme fiables développent des erreurs uniquement lorsqu’ils sont connectés au même port, les composants communs peuvent inclure le canal du contrôleur, le connecteur, le câble, la ligne du fond de panier, le chemin de l’expandeur, l’alimentation, le micrologiciel et le refroidissement autour de ce chemin. Le diagnostic doit prouver que l’erreur suit le port, tout en conservant l’identité du disque, les horodatages et le type d’erreur.

Confirmer que l’erreur suit le port et non le nom du disque

Notez les numéros de série des disques, les identifiants persistants des périphériques, le port du contrôleur ou le PHY HBA, le câble, la baie, le membre du pool ainsi que les compteurs de lecture, d’écriture et de somme de contrôle avant la prochaine vérification. Ne vous fiez pas uniquement aux noms changeants tels que /dev/sdX.

Le parcours de dépannage des disques de TrueNAS insiste sur la collecte des données du pool et de SMART avant d’effacer les erreurs ou de remplacer un périphérique.

Après un échange hors tension, demandez-vous si l’erreur suit le disque, la baie, le câble ou le port du contrôleur. Ne modifiez qu’un seul composant par test afin que le résultat reste interprétable.

Distinguer les erreurs de somme de contrôle de la vérification des erreurs de lecture et d’écriture du disque

Enregistrez le résultat complet de la vérification ainsi que les compteurs de chaque périphérique. Une incohérence de somme de contrôle, un délai d’attente de commande, un secteur illisible et une écriture échouée correspondent à des couches de défaillance différentes.

Oracle indique qu’une vérification ZFS vérifie les sommes de contrôle des données actives, tandis que l’état du pool signale séparément les erreurs de lecture, d’écriture et de somme de contrôle pour chaque périphérique.

Si les erreurs de somme de contrôle augmentent sans erreurs de support et suivent un même chemin physique, suspectez une corruption des données entre la mémoire et le disque ou un transport instable. Si les erreurs de lecture suivent le disque d’un port à l’autre, le disque devient plus probablement responsable.

Associer le disque au contrôleur et à la liaison exacts

Suivez le chemin persistant du disque à travers le contrôleur hôte, l’adresse PCI, l’expandeur SAS ou le port SATA, le boîtier, le câble et la baie. Enregistrez cette correspondance avant de déplacer le matériel.

La vue des périphériques lspci identifie le contrôleur de stockage PCI indépendamment des noms du système de fichiers et du pool, ce qui aide à distinguer un chemin de contrôleur défaillant d’un disque qui a simplement reçu un nouveau nom de périphérique.

Pour un HBA, incluez les informations du PHY et de l’expandeur lorsqu’elles sont disponibles. Deux baies frontales peuvent partager un même câble mini-SAS ou une même ligne d’expandeur, même si l’interface les présente comme des emplacements distincts.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Inspecter les réinitialisations de liaison SATA ou SAS pendant la vérification

Surveillez le journal du noyau dès le début de la vérification. Recherchez les réinitialisations forcées, les échecs de COMRESET, les événements de perte de liaison, les délais d’attente de commande, les erreurs de protocole et les changements de vitesse négociée sur le chemin concerné.

Le guide libATA de Linux décrit la réinitialisation de liaison par port et la récupération après erreur, ce qui explique pourquoi des messages répétés associés à un même port ATA constituent un indice plus probant qu’un avertissement générique du pool.

Conservez le premier message de transport. Les erreurs ultérieures du système de fichiers peuvent n’être que les conséquences de la perte de communication entre le contrôleur et le disque pendant une lecture.

Comparer les compteurs CRC de l’interface et de délai d’attente des commandes

Capturez les attributs et les journaux SMART de chaque disque avant et après une seule vérification. Vérifiez si les compteurs CRC de l’interface ou de délai d’attente des commandes augmentent uniquement sur le chemin concerné.

Unraid explique que les erreurs CRC UDMA se produisent entre le disque et le contrôleur, mettant souvent en cause les câbles, les connecteurs, le routage ou la liaison du contrôleur plutôt qu’un dommage aux plateaux.

Les totaux CRC historiques n’identifient pas le composant actuellement défaillant. Notez la valeur brute, exécutez un test limité et vérifiez uniquement si la valeur a augmenté.

Exécuter les tests du disque séparément de la charge de vérification

Exécutez les tests SMART court et étendu pris en charge lorsque le pool est par ailleurs peu sollicité et que les données sont protégées. Évitez de programmer un test SMART complet en même temps qu’une autre vérification ou qu’une reconstruction.

La référence smartctl de Debian distingue les autotests internes et les journaux d’erreurs du disque de la vérification du système de fichiers effectuée par l’hôte.

Un disque qui réussit un test interne mais produit des erreurs uniquement sur un port de contrôleur renforce l’hypothèse d’un problème sur le chemin. Cela ne prouve pas que le disque est parfait ; continuez donc à le surveiller après avoir changé de port.

Remplacer un seul composant commun et répéter une vérification limitée

Une fois les sauvegardes à jour et le serveur hors tension, faites passer un disque connu comme fiable par le chemin suspect ou remplacez un seul câble, en maintenant les autres variables stables. Ne permutez pas tous les disques simultanément.

Le guide ZimaSpace consacré à un disque RAID exclu par rapport à une baie défectueuse présente la méthode d’échange contrôlé correspondante ; cet article applique cette logique spécifiquement aux erreurs de vérification qui suivent de manière répétée un même port de contrôleur.

Arrêtez la vérification et donnez la priorité à la protection des données si les erreurs augmentent rapidement, si plusieurs disques reliés au même contrôleur se réinitialisent, si le pool se dégrade ou si les applications signalent des fichiers corrompus. Le problème n’est résolu qu’après plusieurs vérifications et opérations d’E/S normales réussies sur le même chemin de port, sans nouvelles erreurs.