hergo Posté(e) le 16 février 2019 Partager Posté(e) le 16 février 2019 (modifié) 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
firlin Posté(e) le 16 février 2019 Partager Posté(e) le 16 février 2019 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 ) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
hergo Posté(e) le 16 février 2019 Auteur Partager Posté(e) le 16 février 2019 (modifié) 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
firlin Posté(e) le 16 février 2019 Partager Posté(e) le 16 février 2019 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. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
pluton212+ Posté(e) le 17 février 2019 Partager Posté(e) le 17 février 2019 (modifié) 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+ 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
hergo Posté(e) le 17 février 2019 Auteur Partager Posté(e) le 17 février 2019 (modifié) 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
pluton212+ Posté(e) le 17 février 2019 Partager Posté(e) le 17 février 2019 Parfait 😎 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.