Pourquoi un serveur domestique ne détecte-t-il un disque NVMe qu’après sa sortie de veille ?

Un disque NVMe peut disparaître après une mise en veille lorsque son contrôleur ou sa liaison PCIe ne parvient pas à sortir correctement d’un état basse consommation lors de la reprise.

Un disque qui fonctionne après un démarrage à froid, mais disparaît uniquement après une suspension, ne présente généralement pas un simple problème de système de fichiers. La panne peut survenir avant que l’espace de noms, la partition, le système de fichiers ou l’application ne soient visibles : le périphérique PCIe peut ne pas être réénuméré, le contrôleur NVMe peut ne pas parvenir à devenir opérationnel, ou une combinaison de paramètres de gestion de l’alimentation peut rendre la liaison inaccessible. Diagnostiquez d’abord le niveau le plus bas qui a disparu et évitez de formater, remplacer ou reconstruire le stockage tant que le chemin du périphérique n’est pas compris.

Déterminez le niveau le plus bas qui disparaît après la reprise

Avant la mise en veille, notez le périphérique PCI, le contrôleur NVMe, les espaces de noms, les partitions, les UUID des systèmes de fichiers, les points de montage et les applications qui utilisent le disque. Répétez les mêmes vérifications immédiatement après la reprise.

Le sous-système NVMe de Linux expose les contrôleurs et les espaces de noms comme des niveaux distincts. La commande nvme list d’Ubuntu aide à distinguer un contrôleur manquant d’un contrôleur toujours présent, mais qui n’expose plus l’espace de noms attendu.

Si la fonction PCI est absente, concentrez-vous sur le micrologiciel, la gestion de l’alimentation de la liaison PCIe et le comportement lors de la suspension. Si le contrôleur reste présent, mais que le périphérique bloc disparaît, concentrez-vous sur la réinitialisation NVMe, les espaces de noms, les erreurs du pilote et l’état opérationnel du contrôleur.

Comparez le démarrage à froid, le redémarrage et chaque état de veille pris en charge

Testez un démarrage à froid, un redémarrage classique, une suspension en veille légère et une suspension profonde uniquement lorsque le système d’exploitation et le micrologiciel les exposent. Notez la transition qui reproduit la panne.

Le noyau Linux distingue la suspension en veille légère, la veille intermédiaire et la suspension vers la RAM, chacune entraînant un niveau différent de réduction de la consommation du périphérique et de la plateforme. La description des états de veille du noyau explique pourquoi un contrôleur NVMe peut reprendre correctement depuis un état peu profond, mais échouer après une transition de plateforme plus profonde.

Une panne limitée à un seul état indique davantage un problème de transition d’alimentation qu’un problème de formatage du disque. Conservez l’état qui fonctionne pendant que vous testez une correction permanente du micrologiciel ou du pilote.

Vérifiez si le périphérique PCIe est réénuméré

Comparez les informations du bus PCI avant la mise en veille et après la reprise, notamment l’adresse du contrôleur NVMe, l’état négocié de la liaison, le pilote du noyau et les compteurs d’erreurs. Enregistrez l’adresse exacte du bus avant le test.

L’utilitaire lspci signale le contrôleur au niveau PCI avant toute intervention de l’espace de noms ou du système de fichiers. Il constitue donc le bon indicateur lorsque l’ensemble du périphérique NVMe semble disparaître.

Si le périphérique n’apparaît plus dans l’énumération PCI, rescanner le système de fichiers ou recréer les points de montage ne peut pas résoudre le problème. S’il reste visible, recueillez les erreurs NVMe et du noyau avant de tenter une réinitialisation du contrôleur.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testez les transitions autonomes vers les états basse consommation du NVMe

Notez les paramètres actuels des états d’alimentation NVMe et vérifiez si les transitions autonomes vers ces états sont activées. Ne modifiez qu’une seule variable liée à l’alimentation pendant un cycle de suspension contrôlé.

ArchWiki documente le comportement d’économie d’énergie du NVMe ainsi que le contrôle de latence APST, utilisé pour limiter la profondeur des états basse consommation auxquels le contrôleur peut accéder lorsque certains matériels reprennent de manière peu fiable.

Une restriction temporaire d’APST est un outil de diagnostic, et ne prouve pas que tous les états profonds sont défectueux. Si le disque résiste à des cycles de reprise répétés uniquement avec une politique d’alimentation moins agressive, comparez les corrections du micrologiciel et du noyau avant de conserver définitivement cette solution de contournement.

Examinez le micrologiciel, le BIOS et le comportement de Modern Standby

Notez la version du micrologiciel de la carte mère, le micrologiciel NVMe, la version du système d’exploitation et toute modification récente du BIOS ou du pilote. Vérifiez si la plateforme utilise la veille traditionnelle ou un modèle d’inactivité moderne à faible consommation.

Le modèle Modern Standby de Microsoft montre que les périphériques pris en charge restent soumis à une gestion de l’alimentation basse consommation contrôlée par la plateforme, au lieu de suivre le même chemin que la veille traditionnelle. Cela peut modifier la manière dont un problème NVMe se reproduit selon les systèmes.

Mettez à jour une seule couche de micrologiciel à la fois et conservez la version précédente ou une méthode de récupération. Ne combinez pas une mise à jour du BIOS, une mise à jour du micrologiciel du SSD et une mise à niveau du système d’exploitation lors d’un même test : il serait impossible d’identifier la modification qui a réussi.

Inspectez la gestion de l’alimentation de la liaison PCIe et de l’exécution

Vérifiez les paramètres ASPM PCIe, l’état de l’alimentation en fonctionnement et si le contrôleur NVMe passe à un état d’exécution suspendu avant la mise en veille du système. Comparez l’emplacement défaillant avec un autre emplacement uniquement si la conception du serveur le permet en toute sécurité.

Les recommandations de Red Hat en matière de gestion de l’alimentation expliquent que la gestion de l’alimentation en fonctionnement et l’ASPM PCIe sont deux mécanismes distincts. Ainsi, désactiver l’un et observer une amélioration ne permet pas automatiquement d’identifier l’autre comme la cause.

Si le problème suit le disque vers un autre emplacement, suspectez le contrôleur ou le micrologiciel. S’il reste lié à un emplacement précis, examinez le micrologiciel de la carte mère, le bifurcage, les lignes partagées, l’alimentation de l’emplacement et l’intégrité du signal.

Récupérez les données en toute sécurité et vérifiez plusieurs cycles de reprise

Lorsque le disque disparaît, conservez les journaux avant d’effectuer un arrêt à froid. Évitez les réinitialisations à chaud répétées si le contrôleur signale un état critique, des erreurs de liaison ou la disparition d’espaces de noms.

La liste de contrôle de récupération d’un serveur personnel de ZimaSpace applique la règle complémentaire suivante : vérifiez la visibilité du matériel et l’état du stockage avant d’exécuter une réparation du système de fichiers ou de restaurer des données.

Le problème est résolu lorsque le contrôleur, l’espace de noms, les partitions, les points de montage et les applications survivent à des cycles répétés de mise en veille et de reprise avec l’état d’alimentation prévu. Conservez une sauvegarde à jour jusqu’à ce que la correction résiste également au redémarrage, aux périodes d’inactivité et à une charge de stockage normale.