Bonjour à tous,

Bonne nouvelle empirique pour la question de @Mic13710 : la mise à jour vers DSM 7.4.1 est passée chez moi ce midi (après libération d'espace via le venv Python + purge du snapshot au redémarrage). Résultat du mdadm --detail /dev/md0 après l'update :

root@NasServeur723:~# cat /etc.defaults/VERSION
majorversion="7"
minorversion="4"
major="7"
minor="4"
micro="1"

root@NasServeur723:~# df -h /
Filesystem        Size  Used Avail Use% Mounted on
/dev/system-root  2.3G  1.6G  598M  74% /
root@NasServeur723:~# sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Fri Jan  3 10:25:56 2020
     Raid Level : raid1
     Array Size : 2490176 (2.37 GiB 2.55 GB)
  Used Dev Size : 2490176 (2.37 GiB 2.55 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Aug  4 14:46:01 2026

Inchangé. Donc confirmé : une simple mise à jour DSM, même avec assez d'espace libéré pour passer, ne déclenche pas le grow automatique de md0 vers les 8 Gio pourtant déjà présents sur mes p1. Ça répond à votre interrogation — le Mode 2 reste bien le seul déclencheur connu à ce stade.

Je garde le ticket ouvert et je poserai les deux questions de @RAHAN-31 (préservation du pool/volume en Mode 2, et existence d'un mécanisme de migration automatique prévu) si le technicien recontacte — sinon je les inclurai dans ma réponse de clôture du ticket.

Mais je pense aussi à tous les autres utilisateurs qui tomberont sur ce même blocage sans avoir nos connaissances techniques ni la patience de creuser en SSH pendant deux jours. Pour un utilisateur lambda qui voit juste "espace disque insuffisant" sans comprendre pourquoi, avec un volume de données rempli à seulement 15-20%, c'est le genre de message qui peut mener directement à un ticket support, une réinstallation complète paniquée, voire un abandon de la mise à jour par peur de casser son NAS. et je ne vous parle pas de surveillance station aucune sauvegarde de configuration

Ce qui manque cruellement, c'est ce que @RAHAN-31 évoquait plus haut : un message d'erreur DSM qui explique la vraie cause ("partition système ancienne, distincte de votre volume de données") plutôt que le message générique actuel qui laisse penser à un problème de stockage. DSM connaît pourtant parfaitement la taille de sa propre partition système — un diagnostic intégré à l'assistant de mise à jour, qui détecterait ce cas précis et proposerait directement les pistes de nettoyage (cache pip, modules Python manuels, etc.) ou orienterait vers le Mode 2 si nécessaire, éviterait à beaucoup de monde ces heures de recherche.

Voila c'est résolu mais pas soigné complètement

Modifié il y a 21 minutes21 min par Pascalou59

il y a 3 minutes, Pascalou59 a dit :

une simple mise à jour DSM, même avec assez d'espace libéré pour passer, ne déclenche pas le grow automatique de md0 vers les 8 Gio

Ce serait pourtant si simple.... Sinon, en lignes de commande ça devrait pouvoir se faire.

Je suis entièrement d'accord avec vous : ce n'est vraiment pas professionnel de la part de Synology non seulement de ne pas avertir clairement la cause d'un problème qui est connu seulement des initiés, mais aussi de ne pas proposer de solution simple autre que le mode 2 (dont on n'est pas sur quelle fonctionne) pour augmenter automatiquement une partition quand les critères pour le faire sont réunis. Cela fait tout de même plus de 2 ans que ce problème existe. Qu'il soit laissé en l'état de gestation depuis tant de temps, qu'il n'y ait aucun communication à ce sujet me surprend. Il serait quelque part logique d'aller au bout du processus, sinon pourquoi augmenter l'espace p1 si au final on ne peut pas l'exploiter sans passer par des opérations qui dépassent largement les connaissances de la grande majorité des usagers.

Mode vieux con => ON

Attention tout de même à ne pas réduire le problème à notre cas relativement favorable p1=8 Gio → md0=2,3 Gio. Le cas de @Mic13710 montre déjà qu'il existe des géométries historiques différentes, celui de @Pascalou59 montre qu'un système peut avoir été modifié hors des chemins prévus par Synology, et il doit exister quantité d'autres héritages issus des migrations, remplacements successifs et configurations RAID/SHR.

Depuis notre canapé, le grow paraît presque trivial. Pour Synology, le vrai problème est probablement de déterminer avec une certitude suffisante quand il est sûr de le faire, et surtout quand il ne faut pas le faire.

C'est finalement pour cela que la réponse à la question laissée sous le coude à @Pascalou59 m'intéresse davantage que nos spéculations sur le déclencheur : savoir si Synology travaille sur un mécanisme officiel de migration qualifiée de ces anciens md0, ou si le Mode 2 restera définitivement la seule voie supportée.