Erreur reconstruction SHR

[Toom]

Bonjour,

Le système m’indique une erreur « System failed to repair » après une reconstruction du SHR suite au changement d’un disque.

Le volume et le groupe de stockage sont pourtant marqués Sain mais le volume affiche l’ancienne capacité et non la nouvelle capacité du groupe.

Le premier changement de disque s’était bien passé et donc considéré secours, mais là c’est le second qui accroît la capacité du système.

Que faire ?

[Toom]

Voici l'état du groupe de stockage.

J'ai replacé le disque 5 de 2To en premier, puis le disque 4 en deuxième avec reconstruction à chaque fois.

Le groupe comme le volume sont marqués sains mais le journal indique une erreur de reconstruction (System failed to repair [Storage Pool 2] with disk [Drive 4]) et la capacité du volume correspond à 4 disques de 2To au lieu de 3x2+12 comme la capacité indiquée du groupe.

[Mic13710]

Il n'y a rien d'anormal dans votre groupe. Il y a bien la capacité totale, soit pour un SHR de 3x2 + 2x12 = 18To (1 disque de sécurisation), ce qui donne en réalité 16,4To

[maxou56]

Il y a 8 heures, Toom a dit :

volume correspond à 4 disques de 2To au lieu de 3x2+12 comme la capacité indiquée du groupe.

Bonjour,

Le Groupe de stockage d'après la capture semble bon.

Mais le volume c'est autre chose (il manque cette capture).

Tu es en Volume multiple ou simple? Il faut que tu augmente la taille du volume.

Modifié le 31 octobre 2020 par maxou56

[Toom]

Le volume est visible tout en bas de la capture.

Capacité total 7.15To, c’est justement le problème, le volume aurait dû prendre tout l’espace disponible dans le groupe qui lui est ok.

C’est un volume simple SHR.

C.F. Capture jointe, le volume fait 7.15To alors que la totalité de la capacité du groupe lui est allouée.

Modifié le 31 octobre 2020 par Toom
Ajout d'information

[Toom]

Bon... je tourne en rond.

Après redémarrage du NAS, j'ai pu demander à étendre le volume mais...

Après avoir demandé à étendre le volume, j'obtiens l'erreur ci-dessous

Le volume indique alors des erreurs au niveau du système de fichiers.

Après la vérification et le redémarrage du système, le groupe de stockage est dans cet état :

Après avoir cliqué sur Réparer, les disques 4 et 5 ne sont plus en erreur et le système est Sain comme indiqué ci-dessous... mais si je demande d'étendre le volume je retourne au point de départ et je ne peux donc jamais exploiter l'espace du groupe de stockage...

 

J'ai besoin d'un coup de main pour m'en sortir, là je ne sais pas quoi faire de plus.

 

 

 

[Mic13710]

Je ne vois pas ce que vous pouvez faire au niveau de DSM. Il faudrait passer en ssh pour réparer le volume. Je crois me souvenir qu'il y a déjà eu cette opération décrite quelque part sur le forum, mais je ne me rappelle plus où.

Le mieux dans votre cas, surtout si vous n'êtes pas familier du mode terminal, c'est de contacter le support via DSM pour qu'ils interviennent sur votre groupe.

[Toom]

Bon... j'essaye de réparer le volume mais il se passe des choses étranges.

Tout d'abord, cela fait 3 fois que je fais une réparation mais étant déconnecté de SSH pour diverses raisons que je connais, je ne vois pas le process total et à chaque fois que je le relance j'ai des erreurs.

Je fais un fsck.ext4 -vfy /dev/vg1/lv qui correspond au volume en question mais j'ai des quantités d'erreur du type "Illegal block number passed to ext2fs_test_block_bitmap #227769335444796 for multiply claimed block map" ou encore des mutiply-claimed blocks par des fichiers dont le nom est "..." :

File /folder/file (inode #3224, mod time Tue Jul 19 15:55:08 2011) 
  has 4 multiply-claimed block(s), shared with 4 file(s):
    ... (inode #462029258, mod time Sun Oct  8 15:24:51 2073)
    ... (inode #462032885, mod time Wed Jan 17 21:37:04 1973)
    ... (inode #462032189, mod time Mon May 20 08:38:19 1974)
    ... (inode #462035900, mod time Thu Oct 30 03:13:08 2014)
Clone multiply-claimed blocks?

Et ensuite

File ... (inode #462036819, mod time Sun Mar 25 11:19:02 2068) 
  has 4 multiply-claimed block(s), shared with 5 file(s):
    <filesystem metadata>
    /folder/file1 (inode #134414, mod time Sun Feb 19 10:18:05 2012)
    /folder/file2 (inode #2754011, mod time Mon Feb  1 17:38:28 2016)
    /folder/file3 (inode #63276, mod time Thu Sep 21 08:44:50 2017)
    /folder/file4 (inode #244580396, mod time Tue Apr  4 00:03:56 2017)
Clone multiply-claimed blocks?

C'est vraiment bizarre ces blocks associés à des fichiers sans nom...

Et accessoirement, quand je réponds oui au fait de cloner les blocks, c'est extrêmement long.

Modifié le 6 novembre 2020 par Toom

[Toom]

Bon, e2fsck est en version 1.42.6 sur mon NAS, bien que celui-ci soit à jour, et apparemment cette version est buggée... 🙄

Il va falloir que je la mette à jour et que j'essaye de réparer mon volume.

 

[Toom]

J'ai enfin réussi, non sans mal, à réparer mon volume en SSH et à l'étendre.

Si cela intéresse quelqu'un je détaillerai mes péripéties et ma solution pour venir à bout de ce problème.

Maintenant que j'ai redémarré le NAS, le Volume 2 sur le DX510 est dégradé...

Un disque est subitement passé en "Non initialisé" alors qu'il est indiqué Sain et que le test Smart rapide ne trouve rien d'anormal (test étendu en cours)...

Je ne vais jamais m'en sortir 

[Mic13710]

Je pense qu'il serait intéressant d'en faire un tuto.

Pour le disque dégradé, une mauvaise manip dans les commandes peut-être ?

Incidemment, je viens de retrouver une procédure pour résoudre le même problème d'extension de groupe.

https://www.nas-forum.com/forum/topic/58702-changement-disques-pas-daugmentation/?do=findComment&comment=1319342758

[Toom]

J'en ferai un tuto alors, et effectivement cela fait partie des commandes que j'ai utilisé.

En revanche, j'ai dû upgrader la version de fsck.ext4, de e2fsck et de la librairie et la réparation automatique se plantait sur la duplication des blocks assignés deux fois.
J'ai dû sélectionner les réparations à effectuer ou non.

Pour le disque dégradé je n'ai rien fait au niveau manip en SSH qui puisse expliquer cela et je n'ai pas touché au deuxième volume.

Je n'ai pas non plus retiré de disque de l'extension et j'ai redémarré immédiatement après l'indication d'erreur pour qu'il remonte le disque, sans succès.
Le test Smart étendu révèle que le disque est sain mais il n'est pas affecté au groupe de stockage.
Je ne comprends pas trop ce qu'il s'est passé et je crains de lancer une reconstruction.
De toute façon l'idée était de dégager l'extension avec l'augmentation de volume sur l'unité principale, donc je vais peut-être attendre mais entre mes difficultés à étendre le volume principal et le volume secondaire qui est dégradé, il ne faudrait pas qu'un autre disque se retrouve en dehors du groupe après un nouveau redémarrage...

Je ne sais pas pourquoi mais je sens que je vais finir par perdre toutes mes datas...