DS216+II : Impossible d'étendre après changement des 2 disques

[AlPri]

Bonjour,

Je viens de changer les deux disques de mon DS216+II (2x8To par 2x16To) avec DSM6.1.

Habituellement, à l'installation du second disque je pouvais demander une extension en même temps et c'était terminé.

En DSM 6.1, impossible de retrouver ou réaliser l'extension, donc je suis passé en DSM 6.2, et j'y suis toujours en rédigeant ce post.

Maintenant, j'ai bien le bouton étendre :

Mais lorsque je l'utilise, il génère une erreur qui met mon volume en Avertissement :

Après avoir fait Ok, voici l'état du volume :

Je lance donc la procédure de vérification sachant que le journal ne contient aucune erreur, et tout redevient normal :

 

 

Si je relance l'action Etendre, de nouveau Avertissement, et un check redevient normal. J'ai fait cette manip 5 fois sans succès (en changement des détails sans succès). Voici mon Groupe de stockage où l'on voit que je pourrais étendre :

 

 

J'ai des Smart Test complet en cours, mais je n'ai pas beaucoup d'espoir.

Existerait-il des journaux plus détaillés qui permettrait de comprendre pourquoi j'ai un passage en Avertissement au moment de l'extension ?

Je ne pense pas qu'un passage en DSM7 ai une influence.

Est-ce que quelqu'un aurait une idée ?

Merci d'avance.

Bien à vous,

Alex

 

 

[firlin]

Bonjour AlPri,

Si je comprend bien tes capture d’écran ton groupe de stockage est bien en accord avec la capacité de tes disques (2*16To => 14.55To au final).
Par contre quand tu vas dans le gestionnaire de volume pour étendre celui-ci cela ne fonctionne pas si je comprend bien ?
Tu as fait un test smart long sur tes deux nouveaux disques ? ou bien un test de surface (badblock ou logiciel du constructeur ) avant de la monter dans le nas ?

Car quand je vois la 3eme capture cela me fait pensé à un probleme sur un des disques

 

 

[AlPri]

Merci Firlin pour ce retour.

Oui, c'est tout à fait exact, impossible d'étendre.

J'ai lancé les smart tests après avoir installés les 2 disques et après avoir rencontrés ces pb car j'ai fait la même conclusion : pb disques. Mais avec ces tailles de disques, c'est très long, donc c'est toujours en cours. Je vais donc attendre la fin et revenir dans j'espère moins de 24h.

Pour info, j'ai réussi à trouver des logs système, mais cela ne semble pas aider :

2022-11-27T14:41:12+01:00 DiskStation synoscgi_SYNO.Storage.CGI.Volume_1_expand_unallocated[13468]: volume_lib.cpp:2013 Fail to set auto fsck file: [/dev/vg1000/lv]
2022-11-27T14:41:12+01:00 DiskStation synoscgi_SYNO.Storage.CGI.Volume_1_expand_unallocated[13468]: VolumeManager.cpp:2001 Failed to ExpandVolumeUnalloc due to filesystem issue
2022-11-27T14:41:12+01:00 DiskStation synoscgi_SYNO.Storage.CGI.Volume_1_expand_unallocated[13468]: VolumeManagerApi.cpp:623 Fail to expand volume unalloc

 

[AlPri]

Bon, les tests complets des deux disques ne révèlent aucune anomalie. Les deux disques sont taggés sain.

Si je relance l'extension du volume, même résultat passage en avertissement, et un redémarrage avec vérification de fichiers remets tout en sain.

Donc impossible d'étendre pour utiliser tout l'espace.

Quelqu'un aurait-il une idée ?

[niklos0]

Eh bien un test plus poussé s'impose avec Seatools et Badblocks. Ce premier est d'ailleur le seul qui ait de la valeur aux yeux de Seagate.

Modifié le 29 novembre 2022 par niklos0

[Lelolo]

Ouvrir un ticket auprès de Syno ?

[AlPri]

Le 29/11/2022 à 07:42, niklos0 a dit :

Eh bien un test plus poussé s'impose avec Seatools et Badblocks. Ce premier est d'ailleur le seul qui ait de la valeur aux yeux de Seagate.

Merci Niklos0 !

Est-ce que ces outils sont dispo sur synology (pas trouvé dans les packages), ou dois-je sortir les disques pour les analyser ?

Le 29/11/2022 à 10:27, Lelolo a dit :

Ouvrir un ticket auprès de Syno ?

Merci Lelolo !

Comment fait-on pour ouvrir un ticket ?

[niklos0]

Le 03/12/2022 à 23:19, AlPri a dit :

Est-ce que ces outils sont dispo sur synology (pas trouvé dans les packages), ou dois-je sortir les disques pour les analyser ?

bad block est un utilitaire linux que l'on peut lancer sur le syno (je te laisse rechercher le tuto disponible sur le site).

Seatools, il faut le lancer en clée USB bootable à partir d'un PC (et peut-être même que ça marche sur un mac).

[AlPri]

Bon après quelques jours pour réaliser une sauvegarde complémentaire de sécurité, me voilà prêt à lancer badblocks.

Pour passer un disque en fail, dans le tuto de @firlin ici,

il est nécessaire de lancer la série de commandes "mdadm /dev/md0 --fail /dev/sdx1" sur les partitions 0, 1 et 2. Ce qui m'intrigue c'est que j'ai 6 partitions (/dev/md0 à /dev/md5). Faut-il passer les 3 commandes sur les 6 partitions ?

Voici les sdb :

Et les md supplémentaires :

Merci d'avance,

Bonne soirée

 

[Mic13710]

Je laisse répondre @firlin pour la partie test.

Je vous donne l'explication pour les md. Votre groupe initial était composé de disques de 2To (md3). Ces disques ont été remplacés par des 6To ce qui a occasionné la création d'un nouvel md de 4To (md4) pour gérer la capacité supplémentaire. Le remplacement des 6To par des 16To a créé un nouvel md de 8To (md5) pour gérer le nouvel apport de capacité. Pour simplifier, chaque md est en fait un RAID, dans votre cas un RAID1. Votre groupe est donc constitué de 3 Raid1. C'est le principe de fonctionnement du SHR qui est ni plus ni moins qu'un RAID hybride où cohabitent plusieurs RAID dans un même groupe.

[firlin]

Bonjour AIPri,
Normalement il faudrait le faire sur les 6 partitions, mais vu que les disques sont en production ( utiliser avec des données dessus ) . Si tu te trompe de commande tu va supprimer les données (cf contrôle destructif ) .
C'est pour cela que je fait des badblock sur les disques avant de le mettre dans un groupe de stockage.

[AlPri]

Bonjour Firlin, Merci !

Pour éviter la commande mdadm, j'ai pris une autre option : mauvaise idée apparemment car j'ai cassé les deux disques.

Voici la manip pour éviter à d'autre de faire :

- J'ai éteint diskstation et retiré le disque 2

- Je l'ai ensuite connecté en eSata externe et rallumé.

- Il s'est mis en sdc, et il était bien failed sur l'IHM

- J'ai lancé la commande badblocks sur sdc avec le plannificateur

- J'ai dû ajouté le f de forçage, et j'ai pu  voir les 2 premières lignes du log,

- Puis j'ai perdu ssh et l'IHM haut de quelque minutes j'ai pu éteindre proprement au bouton

- Au redémarrage, j'ai eu pour chaque disque séparément l'écran de réinstallation !

 

Je suis donc reparti de mon ancien disque + quelques restaurations et tout est à nouveau en route.

Ensuite, j'ai lancé le seatools sur les deux 16T et aucune anomalie.

Par contre, je soupçonne maintenant un pb de filesystem sur les disques d'origine. En effet, lors de la récupération du disque d'origine, il avait créé un nouveau Dossier partagé qui doublonnait un d'origine avec un "_1" au bout du nom du dossier, aussi tous les fichiers se trouvant dans dans la corbeille d'un seul dossier partagé (pas le même) ont un sens interdit comme ceux-ci :

Lorsque je vide la corbeille, la plupart des fichiers sont bien supprimés mais un certain nombre ne s'effacent pas. Lorsque je tente de supprimer en SSH root, j'ai l'erreur suivante :

rm: cannot remove 'ES/ImportExport/Data/@eaDir/expFiles_91': Input/output error

Donc, le e2fsck semble indispensable. Je viens de trouver un post sur @DavFromRouen qui a eu en 2021 exactement le même pb que moi je vais mis accrocher si besoin :

 

Merci à tous !