1812+ : SHR Volume erreur

[hergo]

Bonjour,

Je viens à l'appel à l'aide car j'ai beau regarder les forum, je ne trouve pas ma réponse.

Mon NAS et mon volume Raid SHR ne provient pas d'un précédent NAS. Tous les DD sont compatibles avec la liste sur Synology.com.

Je viens d'acheter un dique pour remplacer un DD plus petit. Et là : "Echec de l'opération car des erreurs sont survenues au niveau du systeme de fichiers" lorsque je veux "Etendre" le volume qui à mis 3 jours à calculer.

J'ai beau rebooter sur les consignes et les LOGS, rien ne fait, j'ai l'impression que Synology me limite la taille de mon volume mais sans vraiment être sur car je n'ai pas d'erreur explicite. J'ai rien dans le journal !

 

Vous trouverez ci-dessous tous les détails sur mes disques, et preuves. Si certains d'entre vous connaissent des parades en lignes de commande en console, pas de soucis.

root@BlackStorm:/# cat /var/log/messages | grep "storage"
2019-02-16T00:42:46+01:00 BlackStorm [53703.804876] init: synostoraged main process (10983) terminated with status 15
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sdb] info cache generated
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sdg] info cache generated
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sdc] info cache generated
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sda] info cache generated
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sdd] info cache generated
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sdf] info cache generated
2019-02-16T00:44:46+01:00 BlackStorm synostorage: synostorage_int_disk.c:317 Disk [sde] info cache generated
2019-02-16T00:44:53+01:00 BlackStorm spacetool.shared: hotspare_repair_config_set.c:37 synostoraged is offline, skip sending SIGHUP
2019-02-16T01:43:18+01:00 BlackStorm synostoraged: cache_monitor.c:1086 Initialize the last check time for flashcache
2019-02-16T01:43:18+01:00 BlackStorm synostoraged: scemd_connector/scemd_connector.c:143 Fail to sendto() for scemd connector client.
2019-02-16T01:43:18+01:00 BlackStorm synostoraged: cache_monitor.c:109 Fail to SYNOScemdConnectorClient() for scemd conncetor.
2019-02-16T01:43:18+01:00 BlackStorm synostoraged: scemd_connector/scemd_connector.c:143 Fail to sendto() for scemd connector client.
2019-02-16T01:43:18+01:00 BlackStorm synostoraged: cache_monitor.c:109 Fail to SYNOScemdConnectorClient() for scemd conncetor.
2019-02-16T13:29:54+01:00 BlackStorm [45925.661331] init: synostoraged main process (10976) terminated with status 15





root@BlackStorm:/# vgdisplay
  --- Volume group ---
  VG Name               vg1000
  System ID
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  15
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               29.08 TiB
  PE Size               4.00 MiB
  Total PE              7623873
  Alloc PE / Size       7623873 / 29.08 TiB
  Free  PE / Size       0 / 0
  VG UUID               7cfQSa-Ou3o-2qAw-kCSA-JCej-v48J-L8MxH5





root@BlackStorm:/# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md1 : active raid1 sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
      2097088 blocks [8/7] [UUUUUUU_]

md2 : active raid5 sda5[9] sdg5[8] sde5[4] sdf5[5] sdd5[6] sdc5[7] sdb5[1]
      23413701888 blocks super 1.2 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]

md4 : active raid1 sdg7[0] sda7[1]
      1953494912 blocks super 1.2 [2/2] [UU]

md3 : active raid5 sdd6[0] sda6[3] sdg6[2] sdc6[1]
      5860195584 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4] sdf1[5] sdg1[6]
      2490176 blocks [8/7] [UUUUUUU_]

unused devices: <none>

Modifié le 16 février 2019 par hergo

[firlin]

Bonjour hergo,

As tu exécute une versification du système de fichiers, comme il le demande ?

Si je comprends bien tu as remplacer le disque 1 par un 9 To  et tu es full niveau raid ( du moins pratiquement )

 

[hergo]

Bonjour Firlin,

Oui j'ai rebooté je ne sais combien de fois, refais le test, puis d'autres tests SMART & Co. Tout ressort à chaque fois sans erreur.

J'ai remplacé un 4To (~3To) par un 10To (~9To).   Avec le 3To j'étais à 25To avec le 9To je suis désormais à 29To logiquement sauf qu'il ne veut pas. Et oui je suis quasi à 96% (Dès 25To).

Après beaucoup de recherches cette après midi j'ai peut-être trouvé une requête à lancer mais je n'ose pas. Je suis Droniste, tous mes films de mes clients si je les perds... et je ne peux pas sauvegarder 25 To 🙂 ailleurs.

Qu'en pensez vous :

 

syno_poweroff_task -d [Press Enter] << This will bring down all services except the SSH.

vgchange -ay [Press Enter] << This will enable the volume

fsck.ext4 -pvf -C0 /dev/vg1/lv [press Enter] << This will try to fix the error, pop out yes/no to let you chose when error show up.

fsck.ext4 -yvf -C0 /dev/vg1/lv [Press Enter] << This will try to fix the error, system will automatic chose yes to fix error.

Il semblerait que juste : fsck.ext4 -pvf -C0 /dev/vg1/lv  est réparé pas mal de personnes dans le même soucis que moi, mais je ne sais pas ce que cela fait ?

Modifié le 16 février 2019 par hergo

[firlin]

Je peux pas trop t'aider j en sais pas assez en ligne de commande Linux pour valider celle que tu sites. Après tu peux attendre la réponse d'autres forumeurs

Mais rien me t’empêche d’ouvrir un ticket auprès du support synology.

 

[pluton212+]

Dans le man fsck.ext4:

(c'est du copier/coller)

Citation

-p:  Automatically repair ("preen") the file system.  This  option  will
              cause  e2fsck to automatically fix any filesystem problems that can
              be safely fixed without human intervention.  If e2fsck discovers  a
              problem  which  may  require the system administrator to take addi‐
              tional corrective action, e2fsck will print a  description  of  the
              problem  and  then  exit  with the value 4 logically or'ed into the
              exit code.  (See the EXIT CODE section.)  This option  is  normally
              used  by the system's boot scripts.  It may not be specified at the
              same time as the -n or -y options.

Citation

-v: Verbose mode.

Citation

-f:  Force checking even if the file system seems clean.

Citation

-y: Assume an answer of `yes' to all questions;  allows  e2fsck  to  be
              used  non-interactively.   This  option may not be specified at the
              same time as the -n or -p options.

Citation

-C: fd  This option causes e2fsck to write completion  information  to  the
              specified  file  descriptor  so that the progress of the filesystem
              check can be monitored.  This option is typically used by  programs
              which  are  running e2fsck.  If the file descriptor number is nega‐
              tive, then absolute value of the file descriptor will be used,  and
              the  progress  information  will  be  suppressed initially.  It can
              later be enabled by sending the e2fsck process  a  SIGUSR1  signal.
              If  the file descriptor specified is 0, e2fsck will print a comple‐
              tion bar as it goes about its business.  This requires that  e2fsck
              is running on a video console or terminal.

Donc en gros:

le -p répare automatiquement le système de fichier, sinon il affiche un code de sortie.

Le -v est un mode "verbeux" donne des indications sur l'avancement de la procédure et sur quoi faire.

Le -f vérifie le système de fichier même s'il semble correct.

Le -y force le "yes" aux éventuelles questions (sur la 2d cde).

Le -C je n'ai pas trop compris 🙂

Modifié le 17 février 2019 par pluton212+

[hergo]

Bonjour,

-C0 : Afficher la barre de progression

Après un dimanche à le passer à trouver une solution c'est bon !

Voici ci-dessous le tuto de toute ce que j'ai fait :

 

J'ai eu une collections de petites merdes, pour ceux à qui cela arriverait voici comment je me suis débrouillé.


Hergo@BlackStorm:~$ df

Vous regardez le "fileSytem" du "Volume 1" : 
Soit : /dev/vg1000/lv
Soit : /dev/vg1/lv

Mon cas sera : /dev/vg1000/lv   (A reporter partout dans la suite ci-dessous)

Hergo@BlackStorm:~$syno_poweroff_task -d
Hergo@BlackStorm:~$vgchange -ay vg1000
Hergo@BlackStorm:~$umount /volume1

umount: /volume1/: target is busy

1° Soit ça fonctionne, allez en 5°
2° Soit ça vous dit qu'il ne peut pas le démonter. Allez en 3°a)

3° a) 

root@BlackStorm:~# e2fsck -nf -C0 /dev/vg1000/lv

Attendez 1 ou 2 heures. Puis 3b.

3° b) "syno_poweroff_task -d" aurait du killer tous les process mais il en reste qui tournent sur volume1. Ils vous disent d'utiliser LSOF, sauf que sur Synology bah... bredouille et pour installer c'est tout un enfer. Utilisez donc cette requete ci-dessous qui vous liste les PID qui sont utilisés sur volume 1 :

Hergo@BlackStorm: sudo find /proc/[0-9][0-9]*/ /proc/[0-9][0-9]*/fd -maxdepth 1 -lname '/volume1/*' -printf "%p %l\n" 2>/dev/null | awk  '{split($1,sf,"/"); print sf[3]}' | sort -u -k1,1

Si les PID sont des sessions SSH (Celles avec lesquels vous êtes connecté) c'est normal, et par conséquent si vous killez tout, le session SSH se referme, vous la ré-ouvrez et de nouveau le même soucis. Il semblerait que ça vienne d'un bug de cette fonction (A lire sur le web). Allez en 4°.

Si les PID restant sont d'autres process, je vous laisse trouver la solution car c'était pas mon cas.


4° Ouvrez 2 Consoles SSH en root "exec sudo -i"
   Sur la 1ere tapez :  /!\ bien mettre le " & " à la fin

root@BlackStorm:~# syno_poweroff_task -d &


Soit la fenêtre se ferme et utilisez l'autre. Allez en 5°
Soit la fenêtre reste.  Allez en 5°


root@BlackStorm:~# vgchange -ay vg1000

  1 logical volume(s) in volume group "vg1000" now active
[1]+  Done



root@BlackStorm:~# fsck.ext4 -pvf -C0 /dev/vg1000/lv

Inodes that were part of a corrupted orphan linked list found.

1.42.6-3211: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)



Comme vous pourrez le voir la réparation n'a pas fonctionnée en automatique.
Il me propose en manuel.



root@BlackStorm:~# fsck.ext4 -yvf -C0 /dev/vg1000/lv


/!\ A PARTIR DE CE MOMENT LA J'AI MIS "YES" partout, et j'ai serré les fesses :( /!\


e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 7733768 was part of the orphaned inode list.  FIXED.
Deleted inode 7736028 has zero dtime.  Fix<y>? yes

Deleted inode 245247780 has zero dtime.  Fix<y>? yes
Inode 292103637 was part of the orphaned inode list.  FIXED.
Deleted inode 292103734 has zero dtime.  Fix<y>? yes
Deleted inode 292123251 has zero dtime.  Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -59414722 -62118840 -(62120456--62120458) -67990887 -2412584619 -2461717177 -2463102803 -4061536861 -4288782941 -5019673181
Fix<y>? yes
Free blocks count wrong for group #1813 (2041, counted=2042).
Fix<y>? yes
Free blocks count wrong for group #1895 (1081, counted=1085).
Fix<y>? yes
Free blocks count wrong for group #2074 (2137, counted=2138).
Fix<y>? yes
Free blocks count wrong for group #73626 (2734, counted=2735).
Fix<y>? yes
Free blocks count wrong for group #75125 (1964, counted=1965).
Fix<y>? yes
Free blocks count wrong for group #75167 (4605, counted=4606).
Fix<y>? yes
Free blocks count wrong (270154593, counted=270154602).
Fix<y>? yes
Inode bitmap differences:  -7411803 -7733768 -7736028 -245247780 -292103637 -292103734 -292123251
Fix<y>? yes
Free inodes count wrong for group #1809 (2462, counted=2463).
Fix<y>? yes
Free inodes count wrong for group #1888 (12, counted=14).
Fix<y>? yes
Free inodes count wrong for group #59874 (113, counted=114).
Fix<y>? yes
Free inodes count wrong for group #71314 (666, counted=668).
Fix<y>? yes
Free inodes count wrong for group #71319 (2187, counted=2188).
Fix<y>? yes
Free inodes count wrong (852696374, counted=852696381).
Fix<y>? yes

1.42.6-3211: ***** FILE SYSTEM WAS MODIFIED *****

     1069763 inodes used (0.13%, out of 853766144)
        4002 non-contiguous files (0.4%)
         564 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 1050687/10442/8488
  6559968406 blocks used (96.04%, out of 6830123008)
           0 bad blocks
        2551 large files

      728152 regular files
      276141 directories
           0 character device files
           0 block device files
           0 fifos
           5 links
       65461 symbolic links (138 fast symbolic links)
           0 sockets
------------
     1069759 files



root@BlackStorm:~# REBOOT


Le DSM redémarre, je vais sur l'interface web, je check le RAID, tout va bien.
Je click sur "étendre" mon volume.
Quelques minutes plus tard, les 29 To sont mis en place.

Je n'ai apparemment rien perdu. En PJ la preuve.

J'attends les spécialistes ici présent pour me dire si j'ai bien fait, en tout cas c'est fait :)

Modifié le 27 juillet 2019 par hergo

[pluton212+]

Parfait 😎