Pourquoi la capacité RAID reste-t-elle inchangée après le remplacement de chaque disque ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

La capacité RAID reste généralement inchangée car une couche dans la pile de stockage expose encore l’ancienne limite. Confirmez que chaque remplacement est un membre actif et entièrement reconstruit, puis comparez la taille rapportée des disques physiques, des partitions membres, du périphérique RAID, de la couche de volume et du système de fichiers monté dans cet ordre. La première couche qui affiche encore l’ancienne taille est normalement celle qui doit être étendue.

Confirmez Que Chaque Remplacement Est Devenu un Membre Actif

Commencez par l’état de l’ensemble plutôt que par l’écran de capacité. Un disque plus grand qui est encore listé comme réserve, cible de remplacement, périphérique en reconstruction ou membre indisponible n’augmente pas encore la taille commune du groupe RAID. Notez le numéro de série, le rôle, le nombre de secteurs utilisables, l’état de reconstruction et les compteurs d’erreurs pour chaque membre avant de modifier quoi que ce soit.

Dans un miroir, la capacité ne peut normalement pas augmenter tant que tous les membres qui définissent le miroir ne sont pas assez grands. Dans un RAID par parité, chaque membre participant à la géométrie actuelle peut également devoir exposer la taille de composant plus grande. La séquence de remplacement sûre consiste à remplacer un disque, attendre une reconstruction propre, vérifier l’ensemble, puis seulement remplacer le disque suivant. Le guide de ZimaSpace sur le remplacement de chaque membre du miroir un à un explique pourquoi la capacité utilisable reste souvent inchangée pendant les étapes intermédiaires.

Trouvez la Première Couche de Stockage Qui Affiche Encore l’Ancienne Taille

Un NAS peut empiler plusieurs limites de capacité indépendantes : disque physique, table de partition, membre RAID, périphérique RAID, mappage de chiffrement, volume physique LVM, volume logique, pool de stockage et système de fichiers. Le remplacement du matériel ne modifie que la première couche. Chaque couche au-dessus doit découvrir ou être informée de la nouvelle limite avant que le partage monté puisse utiliser l’espace supplémentaire.

Notez la taille affichée à chaque couche au lieu d’appuyer plusieurs fois sur un bouton « étendre ». Le diagnostic correct est la première transition où une couche inférieure est plus grande mais la couche suivante reste à l’ancienne taille.

Première couche affichant encore l’ancienne taille Raison probable Vérification sûre suivante
Disque de remplacement Le périphérique est plus petit que prévu, utilise une disposition de secteurs différente ou n’est pas entièrement détecté Comparez modèle, numéro de série, taille logique/physique des secteurs et nombre total de secteurs
Partition membre La disposition de partition ancienne a été clonée sans étendre son secteur de fin Comparez les secteurs de début et de fin de partition sur chaque membre
Périphérique RAID L’ensemble utilise encore l’ancienne taille de composant ou n’a pas terminé son opération d’extension Vérifiez la taille de l’ensemble, la taille des composants, la santé et le support d’extension
Volume ou mappage De nouveaux étendues sont visibles en dessous mais non assignées au-dessus Inspectez les limites du chiffrement, LVM, pool thin ou pool de stockage
Système de fichiers monté Le périphérique bloc a grandi mais le système de fichiers ne l’a pas fait Utilisez la procédure d’extension en ligne ou hors ligne spécifique au système de fichiers

Vérifiez Si Les Partitions de Remplacement Se Terminant Encore à l’Ancienne Limite

De nombreux processus de remplacement copient la table de partition originale afin que les métadonnées RAID commencent au même décalage. Cela protège l’alignement et l’identité du membre, mais peut aussi laisser une grande zone inutilisée après la fin de l’ancienne partition. Le disque physique est plus grand tandis que le membre RAID présenté à l’ensemble est encore de l’ancienne taille.

Comparez les nombres de secteurs plutôt que les étiquettes arrondies en téraoctets. Les disques vendus avec la même capacité nominale peuvent avoir des totaux de secteurs utilisables légèrement différents, et une partition de remplacement sous-dimensionnée peut empêcher l’ensemble de sélectionner une taille de composant commune plus grande. Ne recréez pas les partitions à la légère sur un membre actif ; conservez le secteur de début, le type de partition et la disposition des métadonnées RAID, et effectuez uniquement la modification prise en charge par la plateforme après une sauvegarde vérifiée.

Vérifiez Que La Couche RAID A Bien Été Étendue

Un état sain et des membres plus grands ne prouvent pas que le périphérique RAID lui-même a adopté la nouvelle géométrie. Certains systèmes de stockage s’étendent automatiquement après le dernier remplacement et la reconstruction ; d’autres nécessitent une opération d’extension distincte au niveau de l’ensemble. Sous Linux md, par exemple, le périphérique RAID nécessite encore une étape d’extension explicite après que les périphériques membres sous-jacents exposent la taille plus grande.

Avant de commencer une extension, confirmez que l’ensemble est propre, que chaque membre attendu est actif, qu’aucune reconstruction ou vérification n’est en cours, et que les journaux récents ne contiennent pas de nouvelles erreurs de lecture, écriture, délai d’attente ou liaison. Une opération d’extension modifie la géométrie ou la taille des composants ; elle ne doit pas être utilisée pour masquer un état dégradé non résolu.

Inspectez Les Limites de Chiffrement, LVM et Pool de Stockage Au-dessus du RAID

Si le périphérique RAID est plus grand mais que le volume logique reste inchangé, les blocs supplémentaires attendent dans une couche intermédiaire. Un mappage chiffré peut devoir rescanner le périphérique plus grand. Un volume physique LVM peut devoir reconnaître de nouveaux étendues avant que le groupe de volumes puisse les assigner, et le volume logique doit être étendu avant que le système de fichiers puisse croître.

Ne passez pas directement au système de fichiers parce qu’un outil de capacité rapporte de l’espace libre « quelque part » dans la pile. Vérifiez la taille présentée par chaque objet de mappage et de volume. Dans les systèmes à provisionnement fin ou en pool, distinguez l’espace de pool non alloué de l’espace libre à l’intérieur du système de fichiers monté ; ils ne sont pas interchangeables.

Étendez Le Système de Fichiers Seulement Après Que Son Périphérique Bloc Soit Plus Grand

Un système de fichiers ne peut utiliser que la plage de blocs que son périphérique sous-jacent présente actuellement. Ext4, XFS, Btrfs, ZFS et d’autres systèmes de fichiers ont des règles d’extension, des exigences d’état de montage et des vérifications de sécurité différentes. Identifiez d’abord le système de fichiers et la pile de stockage, puis utilisez sa procédure prise en charge au lieu d’emprunter une commande d’une autre plateforme.

ZFS est un exemple utile de pourquoi l’étape finale peut être spécifique à l’implémentation. Après que tous les membres du miroir sont remplacés, un miroir ZFS peut encore devoir étendre la taille du nouveau périphérique avant que le pool expose l’espace. Btrfs peut également nécessiter que la nouvelle limite du périphérique soit reconnue même si le remplacement s’est terminé avec succès. L’action correcte dépend de la couche qui possède les périphériques membres.

Arrêtez-vous Lorsque La Plateforme Ne Peut Pas Étendre La Disposition Existante Sur Place

Certains contrôleurs RAID, dispositions d’appareils, schémas de partition et systèmes de fichiers ne peuvent pas étendre la configuration actuelle sur place. D’autres peuvent étendre seulement certains niveaux RAID ou exigent que tous les membres correspondent exactement. Si l’interface de gestion n’offre aucun chemin d’extension pris en charge, ne forcez pas des commandes d’une autre pile de stockage simplement parce que les tailles de disque semblent similaires.

Arrêtez-vous et planifiez une migration par sauvegarde et recréation lorsque les historiques des membres sont en conflit, que l’ensemble est dégradé, que les compteurs de santé augmentent, que la disposition des partitions ne peut pas être modifiée en toute sécurité, ou que la plateforme ne documente aucune méthode d’extension sur place. Après une extension prise en charge, vérifiez la nouvelle taille à chaque couche, lancez la vérification d’intégrité de la plateforme, confirmez l’accès normal des applications et conservez l’état avant-après comme nouvelle référence.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.