Bonjour

J' ai un stockage de 8 To le volume n'est a rempli qu' a 17% et impossible d'installer DSM 7.4 car j'ai le message "votre espace disque est insuffisant" sur mon DS723+ alors que l'espace libre est largement dispo

J'ai 2 ssd en cache et 32 Go de mémoire , je ne vois pas pourquoi cette mise a jour ne passe pas .

J'ai demandé a mon Claude il me dit que

root@NasServeur723:~# du -x --max-depth=1 -h / 2>&1 | sort -rh 1.9G / 1.5G et sa réponse /usr à lui seul fait 1.5G sur les 1.9G utilisés —

Sur un DS723+ sain, /usr dépasse rarement 700-900 Mo. À 1.5G, les causes les plus courantes sont :

Claude Pas de dossier isolé énorme — c'est réparti entre les libs (539M), les paquets tiers (/usr/local, 400M) et les composants Synology (/usr/syno, 263M). Ça correspond simplement à un NAS avec beaucoup de paquets installés ,

j'ai immich en docker c'est assez lourd peut etre une cause ? Je n'ai pas de serveur Mail Plus

Claude Non, ce n'est pas ça — et vous avez même la preuve dans votre propre df -h plus haut : tout ce qui touche Container Manager/Docker (/volume1/@appdata/ContainerManager/all_shares/...) est monté sur /dev/synorbd_1, c'est-à-dire volume1, pas la partition système. Synology stocke toujours les images Docker, les volumes de conteneurs et donc les données Immich (photos, base de données, modèles ML) sur le volume de données, jamais sur les 2.3G de la partition système.

Immich peut être aussi lourd qu'il veut sur vos 7 To (dont seulement 18% utilisés, donc large marge là), ça n'a aucun impact sur le blocage de mise à jour DSM.

Le vrai coupable, on l'a déjà identifié : c'est l'accumulation normale de composants système (/usr/lib, /usr/local, /usr/syno — MariaDB, CUPS, tous les hooks DSM) qui remplit progressivement les 2.3G au fil des années et des mises à jour successives. Pas un gros fichier isolé qu'on peut supprimer, juste un totale qui dépasse la marge nécessaire pour l'installateur.

Claude Les deux seules options réelles restent : la migration install, ou attendre/contacter le support Synology pour voir s'ils ont un outil de nettoyage interne plus chirurgical que ce qu'on peut faire en SSH.

Avez vous une idée Merçi

Modifié dimanche à 08:142 j par Pascalou59

DSM est installé sur une partition dédiée non-visible dans DSM.

Tu peux la voir avec la commande suivante :

sudo df -h

Bonjour !! voici le retour mais claude m'a dit que la partition de 2,3Go est insuffisante

root@NasServeur723:~# sudo df -h
Filesystem        Size  Used Avail Use% Mounted on
/dev/system-root  2.3G  1.9G  359M  84% /
devtmpfs           16G     0   16G   0% /dev
tmpfs              16G  244K   16G   1% /dev/shm
tmpfs              16G   36M   16G   1% /run
tmpfs              16G     0   16G   0% /sys/fs/cgroup
tmpfs              16G   30M   16G   1% /tmp
tmpfs             3.2G     0  3.2G   0% /run/user/196791
/dev/loop0         27M  767K   24M   4% /tmp/SynologyAuthService
/dev/synorbd_1    7.0T  1.3T  5.8T  18% /volume1
/dev/usb1p1       916G  118G  799G  13% /volumeUSB1/usbshare
tmpfs             1.0T     0  1.0T   0% /dev/virtualization
/dev/synorbd_1    7.0T  1.3T  5.8T  18% /volume1/@appdata/ContainerManager/all_shares/ActiveBackupforBusiness
/dev/synorbd_1    7.0T  1.3T  5.8T  18% /volume1/@appdata/ContainerManager/all_shares/activity
/dev/synorbd_1    7.0T  1.3T  5.8T  18% /volume1/@appdata/ContainerManager/all_shares/Album Photo Prive
 etc etc

Modifié dimanche à 14:021 j par Pascalou59

Raison pour laquelle les nouvelles installations de DSM depuis la 7.1 ont fait passer la partition système à 7.9Go. Le seul moyen d'augmenter cette partition c'est de refaire une installation complète à partir de 0 (destruction du ou des groupe(s) ou formatage des disques et réinstallation complète de DSM).

Il y a certains dossiers qui peuvent être allégés. Je ne sais plus lesquels, il faudrait chercher sur la partie firmware du forum où ce problème a déjà été mainte fois évoqué.

Bonjour @Mic13710

Ha c'est vraiment pas sympa de la part de synology devoir tout réinstallé la totalité de DSM qui tourne comme une horloge . J'ai fait un ticket d'assistance devoir tout refaire ca me soule énormément

Modifié dimanche à 09:132 j par Pascalou59

On n'est pas (encore) obligé de tout refaire. Comme je l'ai dit, il y a des solutions que tu trouveras dans la section firmware. Tu peux aussi voir avec l'assistance.

Le problème d'espace va probablement être plus critique pour les prochaines versions car s'ils ont augmenté l'espace de la partition système c'est pour pouvoir à terme l'utiliser ce qui obligera tôt à tard à passer par la case réinstallation pour pouvoir continuer à utiliser son NAS dans le futur.

Voilà l'attendu une fois le NAS réinstallé :

Je vais attendre la réponse du support , il y a le robot qui m' a dit de voir coté immich mais apres controle

Vérification des points de montage Container Manager/Docker : j'ai contrôlé les volumes des conteneurs Immich (server, postgres) susceptibles d'écrire massivement — tous les montages pointent correctement vers /volume1/docker/Immich/..., rien n'écrit sur la partition système.

Voici un lien vers un des sujets qui traite de ce problème :

https://www.nas-forum.com/forum/topic/77086-version-72-64570-disponible/page/2/#comment-1319491043

Merci @Mic13710

Je n'avais vu ce post a ce sujet merci !!! malgré la recherche et le sujet date de 2023 .sur 6 pages . Grrrrr j'ai vraiment pas envie de faire une résinstall complète , il y les docker aussi pas de sauvegarde , j'ai Office qui rempli automatiquement par du code python un tableau qui enregistre toute la consommation electrique avec Home assistant .... je vous donnerai la suite que le support donnera je croise les doigts

Modifié dimanche à 12:091 j par Pascalou59

C'est ce que j'appelle une très mauvaise nouvelle… surtout lorsqu'on sort tout juste d'une migration complète d'un Storage Pool d'environ 15 To, dont l'installation DSM remonte à l'origine à DSM 4 et a été mise à jour au fil des années !

Je me retrouve donc avec des HDD neufs et une architecture de stockage entièrement renouvelée, mais avec un DSM qui conserve son ancienne partition système md0 de 2,3 Go au lieu du partitionnement actuel d'environ 7,9 Go.

Certes, parler d'un DSM immédiatement « condamné » serait excessif : DSM 7.3 me convient parfaitement et 7.4 semble encore pouvoir fonctionner sur une ancienne md0.

Mais le problème est ailleurs : je viens de pérenniser le stockage sans réellement pérenniser le système.

À terme, si cette petite partition finit par empêcher les futures mises à niveau de DSM, ce n'est pas tant DSM lui-même qui m'inquiète que tout l'écosystème qui repose dessus : Plex, Container Manager, Home Assistant, HACS et les autres paquets et services.

Ce sont des actifs vivants, qui évoluent rapidement avec leurs dépendances, API, codecs, formats, clients, protocoles, etc. Les figer aujourd'hui reviendrait progressivement à condamner l'ensemble du système, alors même que le matériel et les nouveaux disques pourraient parfaitement continuer à rendre service pendant des années.

Ce qui me gêne surtout est que cette limitation est totalement invisible lors d'une migration.

DSM connaît pourtant la taille et la génération de sa partition système. Il me semblerait donc particulièrement utile que l'assistant affiche, lorsqu'il détecte l'ancien partitionnement, un avertissement du genre :

« Votre système utilise un ancien schéma de partitionnement système. La migration vers de nouveaux disques conservera cette limitation. Une installation fraîche de DSM est nécessaire pour bénéficier du nouveau partitionnement système. »

Une telle information avant de lancer une migration de plusieurs téraoctets pourrait complètement modifier la stratégie choisie par l'administrateur.

Dans mon cas, si j'avais connu cette contrainte avant de commencer, j'aurais au minimum étudié une migration différente permettant de repartir sur un DSM fraîchement partitionné, quitte à accepter une procédure plus lourde.

C'est donc une prise de conscience assez douloureuse après le temps et l'argent investis : la migration des données est réussie, les nouveaux HDD sont là, mais je découvre après coup que j'ai également transporté sur eux une dette technique vieille de plusieurs générations de DSM.

Sur ce point, je trouve vraiment que la communication de Synology est plus que perfectible. Un simple avertissement au bon moment aurait permis de faire un choix éclairé.

Bon... vos échanges m'ont fait mettre le nez dans les entrailles de mon propre NAS et je viens de découvrir quelque chose qui change pas mal ma perception du problème 😅

Mon DS1621+ a une longue histoire derrière lui : son DSM remonte à l'époque de DSM 4 et de son DS1512+, puis a été mis à jour au fil des années jusqu'à DSM 7.3 aujourd'hui.

Je viens parallèlement de terminer une migration complète de mon stockage : mes anciens HDD ont été remplacés par 3 Toshiba MG11 22 To neufs, actuellement constitués en SHR-1 / Btrfs.

Malgré le renouvellement complet des HDD, ma partition système est toujours :

root@Synology:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        2.3G  1.4G  852M  62% /

Jusque-là, je pensais donc simplement avoir hérité de l'ancien partitionnement système de mon installation historique.

Sauf qu'en regardant /proc/partitions, surprise :

sata1p1    8388608
sata2p1    8388608
sata3p1    8388608

sata1p2    2097152
sata2p2    2097152
sata3p2    2097152

md0        2490176
md1        2097088

Les trois HDD neufs possèdent donc déjà chacun une p1 de 8 Gio, alors que md0 reste dimensionné à environ 2,4 Gio.

Si j'ai correctement compris la mécanique, ma situation est donc plutôt :

HDD1 p1 = 8 Gio ─┐
HDD2 p1 = 8 Gio ─┼──> md0 RAID1 ≈ 2,4 Gio ──> filesystem / ≈ 2,3 Gio
HDD3 p1 = 8 Gio ─┘

Autrement dit, le nouveau partitionnement physique existe déjà sur tous les HDD. C'est md0, puis son filesystem, qui n'exploitent pas encore l'espace disponible dans les p1.

Et c'est là que j'aurais une question pour @Mic13710, @PiwiLAbruti ou quiconque aurait déjà rencontré ce cas :

DSM possède-t-il un mécanisme prévu/supporté permettant de faire croître md0 lorsque TOUS ses membres p1 sont déjà passés à 8 Gio ?

Et surtout, si oui, quel est le déclencheur du grow ?

Une mise à niveau majeure de DSM ? Une réparation/reconstruction particulière ? Le remplacement du dernier HDD portant l'ancien partitionnement ? Une opération interne de DSM ? Une intervention du support Synology ?

Je sais que Linux permet techniquement d'agir sur le RAID puis le filesystem avec mdadm/resize2fs, mais ce n'est volontairement pas la question : je cherche à savoir si DSM possède lui-même un mécanisme prévu pour effectuer cette transition, sans bidouille manuelle sur sa partition système.

et @Pascalou59

ton cas pourrait justement être intéressant pour essayer de comprendre cette mécanique.

Ton dernier relevé donne actuellement :

/dev/system-root  2.3G  1.9G  359M  84%  /

On connaît par ailleurs ta configuration : DS723+, 32 Go de RAM, 2 SSD M.2 de 500 Go en cache et 2 IronWolf 8 To en RAID1.

Avant de chercher, comme le suggère @Mic13710, quels dossiers pourraient être allégés afin de récupérer suffisamment d'espace pour tenter normalement la mise à niveau DSM 7.4, pourrais-tu nous donner :

sudo cat /proc/partitions
sudo cat /proc/mdstat
sudo mdadm --detail /dev/md0

Si la dernière commande ne trouve pas /dev/md0, poste simplement son retour : ton DSM présentant actuellement / sous /dev/system-root, /proc/mdstat nous permettra d'abord d'identifier précisément l'array concerné.

Ce qui m'intéresse surtout est de savoir si les partitions système p1 de tes deux IronWolf sont encore à ~2,5 Gio ou si elles sont déjà passées à 8 Gio.

Si elles sont toutes les deux à 8 Gio alors que ton filesystem système reste à 2,3 Gio, nous serions potentiellement dans la même situation malgré nos architectures DATA différentes : RAID1 chez toi, SHR-1 chez moi.

On pourrait alors, dans un second temps, chercher proprement ce qui peut être allégé sans risque dans tes 1,9 Gio occupés, avec l'objectif de permettre à l'upgrade 7.4 que tu souhaites déjà réaliser de démarrer.

Et si elle passe, refaire les mêmes relevés après l'upgrade permettrait simplement d'observer si DSM laisse la partition système logique à ~2,3 Gio ou s'il sait exploiter les p1 de 8 Gio déjà présentes.

Modifié dimanche à 18:491 j par RAHAN-31

Bonjour @RAHAN-31

Voici les différentes info que j'ai récupéré et bonne nouvelle j'ai recu ce matin la demande d'accés du support et la notification de connexion de Taiwan est en cours

 root@NasServeur723:~# du -x --max-depth=1 -h /
4.0K    /initrd
2.5M    /etc.defaults
42M     /.syno
3.0M    /.log.junior
48K     /.old_patch_info
11M     /var.defaults
16K     /opt
47M     /etc
4.0K    /lost+found
4.0K    /mnt
18M     /.syno_rbd
1.5G    /usr
221M    /var
4.0K    /.system_info
60M     /root
4.0K    /volumeUSB1
1.9G    /


sudo cat /proc/partitions
major minor  #blocks  name

   1        0     655360 ram0
   1        1     655360 ram1
   1        2     655360 ram2
   1        3     655360 ram3
   1        4     655360 ram4
   1        5     655360 ram5
   1        6     655360 ram6
   1        7     655360 ram7
   1        8     655360 ram8
   1        9     655360 ram9
   1       10     655360 ram10
   1       11     655360 ram11
   1       12     655360 ram12
   1       13     655360 ram13
   1       14     655360 ram14
   1       15     655360 ram15
 259        0  488386584 nvme0n1
 259        1  488383008 nvme0n1p1
 259        2  488386584 nvme1n1
 259        3  488383008 nvme1n1p1
   8        0 7814026584 sata1
   8        1    8388608 sata1p1
   8        2    2097152 sata1p2
   8        3 7803303248 sata1p3
   8       16 7814026584 sata2
   8       17    8388608 sata2p1
   8       18    2097152 sata2p2
   8       19 7803303248 sata2p3
   9        0    2490176 md0
 250        0    2490176 synorbd_system
 252        0      17472 synofsbd_vm_system
   7        0      32768 loop0
 249        0    9852928 zram0
 249        1    9852928 zram1
   9        1    2097088 md1
   8       32  976762584 usb1
   8       33  976759904 usb1p1
 135      240     122880 synoboot
 135      241      32768 synoboot1
 135      242      86016 synoboot2
   9        3  488381952 md3
   9        2 7803302208 md2
 248        0      12288 dm-0
 248        1  487587840 dm-1
 248        2 7803302208 dm-2
 250        1 7803302208 synorbd_1
 252        1      60480 synofsbd_vm_1

 sudo cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sata1p3[2] sata2p3[3]
      7803302208 blocks super 1.2 [2/2] [UU]

md3 : active raid1 nvme0n1p1[0] nvme1n1p1[1]
      488381952 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sata1p2[0] sata2p2[1]
      2097088 blocks [2/2] [UU]

md0 : active raid1 sata1p1[0] sata2p1[1]
      2490176 blocks [2/2] [UU]

unused devices: <none>
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 : Mon Aug  3 08:31:23 2026
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 2df02df8:2494f7f0:3017a5a8:c86610be
         Events : 0.1239

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sata1p1
       1       8       17        1      active sync   /dev/sata2p1

Modifié hier à 07:431 j par Pascalou59

Salut @Pascalou59 , merci de ton retour,

Peux tu poser cette question au technicien si il prend contact avec toi ?

Mes deux disques disposent maintenant chacun d'une partition système p1 de 8 Gio (8388608 blocs), alors que mon RAID système /dev/md0, créé en 2020, reste limité à 2,37 Gio (2490176).

Puisque DSM 7.4 ne peut actuellement pas être installé faute d'espace sur la partition système, existe-t-il une procédure Synology supportée permettant d'étendre /dev/md0 et son filesystem pour exploiter les 8 Gio déjà disponibles sur les deux partitions membres sata1p1 et sata2p1 ?

Si ce redimensionnement est normalement effectué automatiquement, quel événement le déclenche : upgrade DSM, procédure de réparation, intervention du support, autre ?

bonjour @RAHAN-31

Effectivement, en regardant mes propres relevés que j'ai postés plus haut : mes deux IronWolf ont bien chacun une p1 de 8388608 blocs = 8 GiB, exactement comme tes disques neufs. Donc le nouveau partitionnement physique est déjà là chez moi aussi, sans que md0 (toujours à 2,37 GiB, créé le 03/01/2020 d'après mdadm --detail) en profite.

De mon côté, en parallèle, j'ai identifié et corrigé une partie du problème : un environnement Python installé manuellement (pip install en root pour un script maison) occupait ~190 Mo dans /usr/lib/python3.8/site-packages sur la partition système. Je l'ai déplacé vers un environnement virtuel sur mon volume de données, ce qui devrait libérer assez de marge pour tenter la mise à jour même sans agrandir md0 — mais ta piste sur le redimensionnement reste bien plus intéressante à long terme, vu qu'on va sinon rejouer ce même scénario à chaque mise à jour majeure future.

J' ai poser ta question exactement comme tu l'as formulée

1. Espace récupéré jusqu'ici : 454 Mo disponibles (cache pip vidé), en attente de nettoyer /usr/lib/python3.8/site-packages (~190 Mo de plus) une fois le feu vert du technicien reçu

2. Script énergie : migré et fonctionnel sur le venv /volume1/scripts/energie_venv, tâche planifiée mise à jour

3. En cours : session support avec le technicien Taiwan ce matin

À suivre avec le technicien ! j'attend son feu vert pour la suite

Modifié il y a 21 heures21 h par Pascalou59

Il y a 15 heures, RAHAN-31 a dit :

DSM possède-t-il un mécanisme prévu/supporté permettant de faire croître md0 lorsque TOUS ses membres p1 sont déjà passés à 8 Gio ?

Et surtout, si oui, quel est le déclencheur du grow ?

Je n'en ai aucune idée. Je vois bien que vos 3 partitions sont bien en 7.9Go ce qui les prédisposent à passer sur cette capacité. Maintenant, pourquoi le grow ne s'est pas fait automatiquement, tout simplement je pense parce qu'aucun mécanisme n'est là pour le lancer. Si DSM fonctionne correctement sur la partition d'origine, inutile de l'agrandir. Dès lors, on peut effectivement supposer qu'une nouvelle version va détecter l'espace potentiellement dispo et déclencher l'augmentation du RAID1 sinon ça n'aurait pas de sens.

Attendons la réponse du support pour mieux comprendre le mécanisme.

De mon côté, je vais tenter (pas tout de suite) une opération qui consiste à sortir un des disques de mon 718 pour le formater et reconstruire le groupe. L'idée est de voir si DSM qui s'installe sur le disque partitionne en 7.9Go ou s'il conserve 2.2Go.

Il y a 2 heures, Mic13710 a dit :

De mon côté, je vais tenter (pas tout de suite) une opération qui consiste à sortir un des disques de mon 718 pour le formater et reconstruire le groupe. histoire de voir si DSM qui s'installe sur le disque partitionne en 7.9Go ou s'il conserve 2.2Go.

j'ai aussi mon 718 qui me sert de backup ,je n'ai qu'un seul disque dessus de 8 to ! ? ça vaux le coup de tenter ??

Modifié il y a 21 heures21 h par Pascalou59

Pourquoi pas, mais tu devras refaire tout ton backup (et 8 To ça peut être long).
La capture que j'ai montrée est sur un 218+ qui sert aussi de backup

Je viens de jeter un oeil sur mon 718 qui est en DSM 7.3-81180 j' y vais très tres rarement c'est un disque de 8 To , la partition est déja a 8 go , je vais le mettre en DSM 4.1

Edit je viens de mettre le 718 en 4.1 aucun problème c' était une installation neuve a l'origine de 2025 , donc la partition était déja prête pour le 8 Go . On traine bien bien des casseroles avec les versions plus anciennes

 sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sun Jan 19 13:01:53 2025
     Raid Level : raid1
     Array Size : 8388544 (8.00 GiB 8.59 GB)
  Used Dev Size : 8388544 (8.00 GiB 8.59 GB)

Modifié il y a 21 heures21 h par Pascalou59

Bonjour a tous

@RAHAN-31

Retour du support sur ta question (pas formulée exactement comme tu l'as demandée, mais ça y répond indirectement) :

Nous avons vérifié l'historique Bash, mais il ne contient pas les commandes exécutées précédemment. Par conséquent, nous ne pouvons pas confirmer exactement quels modules ont été installés manuellement dans /usr/lib/python3.8/site-packages.

Nous vous recommandons de supprimer uniquement les dossiers correspondant aux modules que vous avez installés manuellement. Veuillez ne pas supprimer l'intégralité du dossier site-packages.

Par précaution, nous vous suggérons de copier les dossiers concernés vers un autre emplacement sur le volume, par exemple sous /volume1, avant de les supprimer. Veuillez éviter d'utiliser directement la commande rm sans effectuer de sauvegarde préalable.

Si vous n'êtes pas certain des fichiers ou dossiers pouvant être supprimés en toute sécurité, une autre option plus sûre consiste à réinstaller DSM.

Concernant la partition système, votre NAS utilisait à l'origine une partition système d'environ 2,3 Go. Lorsque les disques ont été remplacés, le système a réservé de l'espace supplémentaire sur les nouveaux disques en raison du nouveau mécanisme, mais la partition système existante est restée à environ 2,3 Go.

En temps normal, après une réinitialisation de Mode 2 et une réinstallation de DSM, ce dernier devrait allouer une partition système de 8 Go.

Vous pouvez envisager de sauvegarder d'abord la configuration du système, de réinstaller DSM, puis de restaurer la configuration du système par la suite.

Donc a priori : pas de mécanisme de grow automatique de md0 malgré les p1 déjà à 8 Gio sur les disques. Seule la réinstallation complète (Mode 2) déclenche la réallocation. Ça confirme ta lecture initiale, malheureusement — la présence de l'espace physique ne suffit pas, il faut le déclencheur de réinstallation pour que DSM en profite.

Autre découverte en creusant de mon côté, qui pourrait vous intéresser à tous les deux : en supprimant des paquets Python installés manuellement dans /usr/lib/python3.8/site-packages (190 Mo), l'espace ne s'est pas libéré immédiatement dans df -h. En creusant, j'ai trouvé un dossier /.syno_rbd/snapshot.dat de 126 Mo apparu au moment exact de la suppression — visiblement un mécanisme de snapshot/rollback de sécurité que DSM déclenche automatiquement lors de modifications importantes sur la partition système. L'espace ne sera vraisemblablement libéré qu'au prochain redémarrage propre. Je suis en pleine sauvegarde Active Backup (encore 4-5h), donc je testerai le redémarrage une fois terminée et je confirmerai si ça résout l'écart.

Aute point important surveillance station n'a pas de sauvegarde meme les réglages pour toutes les caméras !! je trouve vraiment que synology n'apporte pas de solution et c'est vraiment abuser , a moins de tout refaire il y a beaucoup de temps a passer meme avec toutes les sauvegardes diverses

A suivre

Modifié il y a 59 minutes59 min par Pascalou59

Merci @Pascalou59 pour avoir complété la réponse du support, là c'est beaucoup plus clair !

Leur proposition confirme donc bien que, dans ton cas particulier :

p1 physiques = 8 Gio
md0 historique = ~2,37 Gio
            ↓
Mode 2 + réinstallation DSM
            ↓
partition système = 8 Go

Et le fait qu'ils proposent ensuite de restaurer la configuration DSM laisse logiquement penser que le pool et le volume DATA existants sont conservés.

Mais c'est justement le dernier point que j'aimerais verrouiller explicitement, car les conséquences ne sont évidemment pas les mêmes entre « réinstaller DSM » et « reconstruire le stockage ».

Si ton ticket est toujours ouvert, pourrais-tu leur poser cette dernière question, idéalement en anglais pour éviter toute ambiguïté :

Can you please confirm that, in this specific situation, performing a Mode 2 reset followed by DSM reinstallation will recreate the system partition at approximately 8 GiB while leaving the existing DATA partitions, RAID storage pool, volume and all user data completely untouched?

Leur réponse permettrait de savoir précisément où se situe la frontière de l'opération.

Ton retour concernant Surveillance Station illustre d'ailleurs parfaitement le problème suivant : préserver les DATA ne signifie pas nécessairement préserver l'ensemble de l'environnement applicatif. La configuration DSM, les configurations propres aux paquets et leurs interdépendances constituent également des actifs qu'il faut pouvoir restaurer.

Merci encore de nous faire suivre les échanges avec le support.

Modifié il y a 41 minutes41 min par RAHAN-31
Modification du post précédent de @Pascalou59

Recourir à un reset mode 2 me semble un poil excessif. Il faudrait aussi savoir si une simple mise à jour de DSM vers une version ultérieure déclenche une augmentation automatique de la partition système de 2.3Go à 7.9Go si p1 est à 8Go.

@Mic13710

Tout à fait d'accord. C'est même désormais le test le plus intéressant et le moins intrusif : si @Pascalou59 récupère suffisamment d'espace après son reboot pour lancer normalement 7.4, un relevé df / proc/partitions / mdadm avant et après nous dira directement si l'upgrade constitue le fameux déclencheur. Le Mode 2 ne viendrait qu'ensuite si nécessaire... malheureusement 🤒, on vient de gagner au passage une migration Data mine de rien 🥳
Donc Wait and See la réponse du tech à notre question concernant la préservation du poo/volume Data et/ou celle de son upgrade...

Pas simple cette histoire de partition système. Attendons la réponse de @Pascalou59 pour en avoir le coeur net.

Il y a 23 heures, Mic13710 a dit :

De mon côté, je vais tenter (pas tout de suite) une opération qui consiste à sortir un des disques de mon 718 pour le formater et reconstruire le groupe. L'idée est de voir si DSM qui s'installe sur le disque partitionne en 7.9Go ou s'il conserve 2.2Go.

Finalement, ça ne sera pas possible dans mon cas. Il faudrait pour ce faire que j'ai environ 5.6Go inutilisés en fin de disque. Or tout le disque est exploité. Si DSM crée un partition à 7.9Go, je ne pourrais pas reconstruire le groupe avec l'espace restant. La faute à une augmentation de l'espace de donnée que j'avais faite il y a bien longtemps pour exploiter tout le disque. A l'époque, il y avait quelques Go qui étaient non exploités après la création du groupe. J'ai joué au plus malin et du coup je n'ai plus cet espace qui avait probablement été laissé intentionnellement par Synology pour faire face à des modifications ultérieures.
Il ne me reste plus qu'à tout reconstruire si je veux changer la taille de ma partition système.

@Pascalou59
Une dernière réflexion issue de la réponse du support, que je te laisse simplement sous le coude si ton échange avec eux se poursuit.

Finalement, au-delà de savoir si 7.4 déclenche ou non le passage de md0 de ~2,37 Gio à ~8 Gio, la question qui conditionne vraiment la stratégie à long terme serait de savoir si Synology prévoit un mécanisme officiel permettant un jour cette migration automatiquement, sans passer par un Mode 2.

Car les conséquences sont complètement différentes :

Mécanisme prévu
      ↓
rester en 2,37 Gio peut avoir du sens
et attendre sa disponibilité

Mécanisme non prévu
      ↓
autant envisager le Mode 2 au moment
où les conditions sont les plus favorables

Si tu juges le moment opportun et que ton ticket est toujours ouvert, voilà la question que je poserais au support :

Synology support has confirmed that replacement drives may already have 8 GiB physical system partitions (p1) while the existing legacy /dev/md0 system RAID remains limited to approximately 2.37 GiB.

Is Synology planning or developing a supported automatic migration mechanism that would allow a future DSM update to expand or recreate the legacy system RAID and filesystem to use the already available 8 GiB partitions, without requiring a Mode 2 reset and DSM reinstallation?

Or should systems in this situation be considered permanently limited to the legacy ~2.37 GiB system partition until a Mode 2 reset/reinstallation is performed?

Aucune urgence à la poser : je te la laisse simplement sous le coude si l'occasion se présente. 😉