La source prouve que le remplacement des deux membres RAID 1 par des disques plus grands n’agrandit pas automatiquement le système de fichiers utilisable. Un utilisateur a remplacé avec succès deux disques de 500 Go par deux disques de 1 To, un à la fois, et a laissé ZimaOS effectuer une reconstruction après chaque remplacement. À ce stade, les deux membres physiques faisaient 1 To, mais le périphérique RAID et le système de fichiers Btrfs n’exposaient encore que l’ancienne capacité de 500 Go.
Sur ZimaOS+ 1.5.4, cet utilisateur a ensuite terminé l’extension via SSH avec mdadm --grow /dev/md0 --size=max, attendu la récupération/resynchronisation qui en a résulté, puis exécuté enfin btrfs filesystem resize max sur le système de fichiers monté. Ils ont indiqué que l’interface graphique et df puis affichait la capacité supérieure. Il s’agit d’une vérification communautaire solide, mais cela reste une procédure CLI manuelle, et non une procédure actuelle via l’interface graphique d’IceWhale.
Sauvegardez vos données avant de commencer l’extension de capacité
Le RAID 1 protège contre la défaillance d’un membre ; il ne protège pas contre les erreurs de manipulation, les dommages aux métadonnées du tableau, les erreurs du système de fichiers ni un problème affectant le second disque pendant la reconstruction.
Ne remplacez qu’un seul membre RAID à la fois
- éteignez l’appareil ;
- remplacez le premier ancien disque par le disque plus grand ;
- démarrez ;
- utilisez la récupération ZimaOS pour reconstruire ;
- attendez que la récupération soit complètement terminée.
Répétez pour le second membre
Ce n’est qu’après la fin de la première reconstruction que l’utilisateur a éteint l’appareil et remplacé le second disque, puis relancé la récupération via l’interface graphique et attendu la fin complète de l’opération.
À ce stade, le tableau était sain sur deux périphériques physiques plus grands, mais sa taille correspondait encore à celle historique des membres.
L’utilisateur de la communauté a ensuite agrandi le tableau mdadm
La commande source était :
sudo mdadm --grow /dev/md0 --size=maxIls ont vérifié la géométrie du nouveau tableau avec mdadm --detail et a attendu que le nouvel état de récupération/resynchronisation soit terminé.
Ne supposez jamais que votre tableau est /dev/md0; identifiez d’abord le tableau réel.
Ensuite, le système de fichiers Btrfs a dû être étendu
La source s’est terminée par :
sudo btrfs filesystem resize max /your/mounted/filesystemUtilisez le chemin Btrfs réellement monté plutôt que de copier littéralement l’espace réservé.
Pourquoi deux étapes de redimensionnement étaient nécessaires
- le périphérique RAID md Linux ;
- le système de fichiers Btrfs qui se trouve au-dessus.
Les deux éléments doivent exposer la capacité supérieure avant que les utilisateurs puissent voir l’espace supplémentaire.
Considérez ceci comme une procédure communautaire spécifique à une version
L’utilisateur source a explicitement exécuté ZimaOS+ 1.5.4. La version actuelle de ZimaOS est plus récente et le comportement de la gestion du stockage peut avoir changé. Avant d’exécuter une procédure manuelle mdadm --grow sur un stockage de production, vérifiez que l’interface ne propose toujours aucune option d’extension prise en charge et envisagez de demander à l’assistance d’IceWhale la procédure actuelle.
Vérifiez l’état du RAID avant chaque remplacement physique
Avant de remplacer le premier disque — puis à nouveau avant de remplacer le second — vérifiez que le tableau est sain et entièrement synchronisé. Commencer le second remplacement avant la fin de la première reconstruction supprime la redondance sur laquelle vous comptez pendant la mise à niveau.
Notez les numéros de série des membres afin que le disque physique retiré corresponde au membre logique affiché par ZimaOS.
Les disques de remplacement doivent offrir une capacité réelle suffisante
Des disques de capacité nominalement égale peuvent différer légèrement quant au nombre de secteurs utilisables. L’extension la plus sûre utilise des disques de remplacement nettement plus grands que les anciens membres et au moins aussi grands les uns que les autres.
Si le deuxième disque de « 1 To » est légèrement plus petit que le premier, l’étape d’extension/reconstruction de md peut ne pas se dérouler comme prévu.
Prévoyez plusieurs cycles de resynchronisation
Le processus décrit dans la source a effectué une reconstruction après le premier remplacement physique, une autre après le second, puis est entré dans un nouvel état de récupération/resynchronisation après le mdadm --grow. Cela signifie qu’une mise à niveau de capacité peut prendre beaucoup plus de temps que le simple remplacement de deux disques.
Maintenez le NAS sur une alimentation fiable et évitez les redémarrages inutiles pendant chaque phase de récupération.
Vérifier le périphérique bloc et le système de fichiers à la fin
Après le redimensionnement final de Btrfs, vérifiez le résultat à plusieurs niveaux :
-
mdadm --detail— géométrie du RAID md ; -
df -hou les outils du système de fichiers Btrfs — capacité utilisable du système de fichiers ; - Interface de stockage de ZimaOS — taille attendue du pool et état sain.
Si une couche affiche encore l’ancienne taille, arrêtez-vous et recherchez la cause au lieu de répéter aveuglément les commandes d’extension.
FAQ sur l’extension du RAID 1
Un seul disque plus grand peut-il augmenter immédiatement la capacité du RAID1 ?
Non. Le miroir reste limité par le membre le plus petit et par la géométrie historique du tableau.
Le remplacement des deux disques plus petits a-t-il automatiquement augmenté la capacité dans la source ?
Non. L’utilisateur devait encore étendre le tableau md, puis redimensionner Btrfs.
Le processus manuel d’extension a-t-il été confirmé par les sources ?
Oui, de la part d’un utilisateur de ZimaOS+ 1.5.4. Il ne s’agissait pas d’une procédure officielle d’IceWhale.
