The source user expected CasaOS “Merge” to turn the small internal eMMC plus an external SSD into one large physical system partition. That is not what the feature does. The merge can present multiple storage locations together under CasaOS's /DATA L’utilisateur s’attendait à ce que la fonctionnalité « Fusionner » de CasaOS transforme la petite mémoire eMMC interne et un SSD externe en une seule grande partition système physique. Ce n’est pas ce que fait cette fonctionnalité. La fusion peut présenter plusieurs emplacements de stockage ensemble sous la section «
la vue, mais le système de fichiers racine Linux, le gestionnaire de paquets, le répertoire racine de Docker et chaque disque physique existent toujours sous-jacents. apt-get upgrade Cela explique le résultat observé : l’interface affichait des centaines de gigaoctets libres dans le stockage système combiné, tandis que échouant avec est ensuite réapparue /DATA et la puce interne semblait à nouveau pleine. Une capacité logique plus importante dans
ne déplaçait pas comme par magie toutes les écritures au niveau de la racine vers le SSD.
L’utilisateur a spécifiquement posé une question sur la fonctionnalité bêta de fusion de CasaOS
Zima-Giorgio a d’abord suggéré de déplacer les images et les volumes Docker vers un autre périphérique de stockage. L’auteur du message a précisé que les volumes Docker n’étaient pas le principal problème : il demandait si la fonctionnalité Fusionner de l’interface de stockage de CasaOS était réellement fiable.
Un autre utilisateur a signalé une fusion réussie
radioamerica7 a répondu avoir fusionné le stockage et que cela « fonctionnait comme prévu », sans aucun problème.
Cela a encouragé l’auteur du message à essayer, mais ce succès à court terme ne répondait pas à la question fondamentale concernant le système de fichiers racine.
L’auteur du message a ajouté un SSD et le processus de fusion s’est terminé facilement
Xan a ensuite ajouté un SSD via le câble en Y et l’a fusionné avec le stockage CasaOS. L’interface indiquait toujours que la puce interne était de petite capacité, mais l’espace de stockage combiné disposait de centaines de gigaoctets libres.
Pendant plusieurs jours, la configuration a semblé fonctionner.
Puis les symptômes de manque d’espace au niveau de la racine sont réapparus
- L’auteur du message a commencé à observer des symptômes familiers :
- des conteneurs Docker qui ne démarrent pas correctement ;
-
apt-get upgradedes erreurs PHP ;échouant avec; - espace insuffisant sur le périphérique
la puce interne signalant des informations d’espace libre erronées ou indéfinies.
Il s’agit de l’élément de preuve le plus important de cette discussion.
CasaOS a historiquement utilisé MergerFS pour l’agrégation de /DATA /DATA. Un exemple historique montre que la racine Linux était toujours montée séparément, tandis que l’implémentation CasaOS LocalStorage d’IceWhale et l’historique public des problèmes décrivent la vue fusionnée comme une combinaison de type MergerFS de la zone de fichiers de CasaOS et du stockage ajouté sous /DATA s’étend sur plusieurs chemins sous-jacents.
Voir l’architecture de stockage fusionné de CasaOS.
MergerFS n’augmente pas le système de fichiers racine ext4
Les fichiers écrits dans des chemins situés en dehors de l’arborescence fusionnée — comme les données du gestionnaire de paquets, les journaux, une partie du répertoire racine par défaut de Docker et les fichiers système Linux habituels — continuent de consommer l’espace du système de fichiers racine physique.
C’est pourquoi apt peut manquer d’espace même lorsque l’arborescence fusionnée /DATA l’interface indique une grande capacité libre.
Les images et volumes Docker nécessitent leur propre plan de migration
C’est pourquoi Giorgio a d’abord orienté l’utilisateur vers le déplacement des images et des volumes Docker. Les données des applications peuvent être volumineuses, et la modification du pool de stockage visible dans CasaOS ne déplace pas nécessairement le répertoire racine de Docker ni chacun des volumes existants.
Avant de modifier les chemins de stockage de Docker, sauvegardez la configuration des conteneurs et les données AppData, puis suivez une méthode actuelle de migration de CasaOS/Docker adaptée au système d’exploitation hôte installé.
La fonction source était explicitement étiquetée comme bêta
L’OP a indiqué à plusieurs reprises que la fonction de fusion était en version bêta. L’historique public des problèmes de CasaOS contient également d’anciens bogues liés au stockage fusionné et des demandes d’évolution de la conception. Considérez-la comme une couche pratique de mutualisation, et non comme un substitut à la compréhension de la disposition sous-jacente des disques et de la racine.
Une disposition de stockage plus prévisible sépare les rôles
Pour un petit serveur domestique eMMC/SBC, une conception plus claire serait :
- le système/la racine sur un périphérique système disposant d’une marge libre suffisante ;
- Docker/AppData sur un SSD ou un autre chemin de stockage choisi délibérément ;
- les médias volumineux/téléchargements sur un stockage de grande capacité distinct ;
- une sauvegarde sur un autre appareil.
Cela facilite la réponse à la question « quel disque physique est plein ? » plutôt que de se fier à un chiffre fourni par une interface de stockage mutualisé.
FAQ sur la fusion du stockage de CasaOS
La fusion du stockage de CasaOS a-t-elle donné à l’utilisateur source une capacité /DATA visible plus importante ?
Oui. La vue fusionnée affichait des centaines de gigaoctets libres après l’ajout du SSD.
Cela a-t-il empêché le stockage interne/racine de se remplir à nouveau ?
Non. L’OP a ensuite rencontré des symptômes de manque d’espace au niveau de la racine, notamment des échecs apt-get upgrade.
La fusion de /DATA signifie-t-elle que la partition racine Linux s’agrandit physiquement ?
Non. Le regroupement de type MergerFS combine des chemins au niveau du système de fichiers ; il n’agrandit pas la partition racine sous-jacente.
