Solution communautaire

Le stockage de ZimaOS est passé en lecture seule : diagnostiquer les déconnexions RAID et les erreurs d’E/S SATA

A May 2026 RAID 5 troubleshooting thread where ZimaOS entered read-only protection after disks temporarily dropped from the array. The RAID later recovered, while SMART logs showed interface CRC and I/O communication errors rather than a simple bad-sector diagnosis.

Lorsqu’un ensemble RAID devient soudainement accessible en lecture seule, le remettre de force en lecture-écriture ne doit pas être la priorité. La question la plus importante est de savoir pourquoi l’ensemble a perdu confiance en un ou plusieurs disques.

Dans cette discussion de mai 2026, un RAID 5 composé de quatre disques est passé en mode lecture seule préventif après la disparition temporaire d’un disque membre. L’ensemble est ensuite revenu à l’état sain [UUUU] et a commencé une longue opération de protection/resynchronisation, mais les déconnexions du disque se sont reproduites. La discussion est alors passée de « comment réactiver l’accès en écriture ? » à l’étude du chemin de communication matériel.

L’ensemble est passé en mode lecture seule préventif

Panneau de stockage RAID 5 de ZimaOS affichant une protection en lecture seule avec un disque de 18 To manquant dans l’ensemble
La capture d’écran originale montrait l’absence d’un membre du RAID, tandis que ZimaOS protégeait l’ensemble contre de nouvelles écritures.

La discussion ne montrait pas que l’utilisateur avait accidentellement activé un interrupteur de lecture seule. L’analyse de la communauté a considéré cet état comme la réaction à une condition de stockage dégradée ou instable.

Le RAID pouvait récupérer tout en présentant un problème sous-jacent

Après le redémarrage et la récupération, les quatre membres du RAID étaient de nouveau visibles et l’ensemble affichait « Protection en cours ».

Panneau RAID 5 de ZimaOS affichant les quatre disques actifs pendant la protection et la resynchronisation de la parité
Une liste de membres affichant un état sain en vert n’expliquait pas pourquoi les disques s’étaient déconnectés auparavant ; l’ensemble avait encore besoin de temps pour se resynchroniser.

Redémarrer à plusieurs reprises pendant une resynchronisation de la parité peut relancer ou prolonger les opérations de récupération. La communauté conseillait de laisser l’ensemble terminer son opération de protection tout en recherchant la cause de la disparition des disques.

Les tests SMART étaient réussis, mais l’historique des erreurs d’interface était important

Les deux disques Toshiba indiquaient un état SMART général réussi, sans secteurs réalloués ni secteurs en attente dans les données partagées. Il n’était donc pas justifié de conclure simplement que « les disques étaient définitivement hors service ».

Cependant, les journaux SMART indiquaient également des compteurs CRC Ultra DMA ainsi que plusieurs erreurs de commande ICRC/ABRT. Ces champs sont généralement associés à des problèmes de communication entre un disque et l’hôte, plutôt qu’à de simples défauts du support. La communauté s’est donc concentrée sur les câbles de données SATA, l’alimentation, la stabilité du contrôleur, le micrologiciel et les réinitialisations répétées de la liaison.

Ne forcez pas le retour en lecture-écriture d’un ensemble dégradé

La discussion ne contient aucune commande publiée par IceWhale permettant de contourner cet état de protection en toute sécurité. Pour des recommandations durables, la limite correcte est la suivante : sauvegardez les données accessibles, vérifiez l’état de l’ensemble, inspectez les connexions physiques et diagnostiquez la déconnexion avant d’essayer de contourner la protection.

Utilisez le panneau de stockage actuel pour confirmer l’état de l’ensemble

La version actuelle de ZimaOS affiche l’état du stockage et celui des disques membres sous Réglages > Stockage. Si vous diagnostiquez un problème sur une version récente, vérifiez comment l’interface Stockage actuelle signale l’état de l’ensemble et de ses disques membres avant de tirer des conclusions à partir de cet incident de 2026.

FAQ sur les RAID en lecture seule de ZimaOS

ZimaOS a-t-il changé aléatoirement un RAID sain en lecture seule ?

Les éléments disponibles indiquent des déconnexions de disques membres. L’état de protection est apparu en même temps qu’un disque manquant, et non comme un simple changement isolé d’un réglage de l’interface.

SMART a-t-il prouvé que les disques Toshiba étaient défaillants ?

Non. L’état SMART général était réussi et les compteurs courants de défaillance des secteurs étaient à zéro, même si les journaux contenaient d’importantes erreurs de communication d’interface.

Que dois-je examiner lorsque des erreurs CRC ou ICRC apparaissent ?

La communauté s’est concentrée sur les câbles SATA, les connexions d’alimentation, la stabilité du bloc d’alimentation, le comportement du contrôleur, le micrologiciel et la récurrence des déconnexions du même disque ou du même port.

IceWhale a-t-elle fourni un diagnostic officiel de la cause première ?

Non. La discussion publiée s’est conclue par une analyse matérielle de la communauté, sans conclusion d’ingénierie de la part d’IceWhale.