Zetsubou

Je vais prendre le temps de RTFM demain à la première heure, merci déjà de tous les conseils. EDIT - 18/05/2017. Ne voyant rien sous badblocks comme secteur realloué ou bloc défaillant sur l"intégralité des disques, ni aucune erreur dans /dev/dm-0, mais par contre il existe un inode corrompu en vérifiant /dev/mapper/vg1000-lv, je vais déjà commander les derniers disques manquants pour ma sauvegarde totale. J'ai accès à mes données pour le moment sous DSM (et les plus critiques ont été contrôlées sur les backups dans la nuit). En profiter pour contrôler les autres disques de sauvegarde (moins importants) déjà existants dans la même foulée, ajouter les nouveaux (après contrôles d'usage), puis recommencer mes volumes dans le DS2413+ de zéro. Pour être plus sûr d'ici le prochain mois - le temps de recevoir, contrôler, copier, recommencer les volumes autrement et repeupler les données dans le sens inverse. Merci du temps accordé hier pour m'aider, mais me grattant la tête sur comment agir au mieux alors que l'on n'avançait plus mon souci, je pense qu'il me sera nécessaire de repartir proprement sur le NAS (comme beaucoup d'autres l'ont déjà fait avec les erreurs de système de fichiers).

ps -aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 24236 4360 ? Ss May17 0:07 /sbin/init root 2 0.0 0.0 0 0 ? S May17 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S May17 0:01 [ksoftirqd/0] root 4 0.0 0.0 0 0 ? S May17 0:01 [kworker/0:0] root 5 0.0 0.0 0 0 ? S< May17 0:00 [kworker/0:0H] root 7 0.0 0.0 0 0 ? S May17 0:00 [migration/0] root 8 0.0 0.0 0 0 ? S May17 0:00 [rcu_bh] root 9 0.0 0.0 0 0 ? S May17 0:03 [rcu_sched] root 10 0.0 0.0 0 0 ? S May17 0:00 [watchdog/0] root 11 0.0 0.0 0 0 ? S May17 0:00 [watchdog/1] root 12 0.0 0.0 0 0 ? S May17 0:00 [migration/1] root 13 0.0 0.0 0 0 ? S May17 0:01 [ksoftirqd/1] root 15 0.0 0.0 0 0 ? S< May17 0:00 [kworker/1:0H] root 16 0.0 0.0 0 0 ? S May17 0:00 [watchdog/2] root 17 0.0 0.0 0 0 ? S May17 0:04 [migration/2] root 18 0.0 0.0 0 0 ? S May17 0:00 [ksoftirqd/2] root 19 0.0 0.0 0 0 ? S May17 0:00 [kworker/2:0] root 20 0.0 0.0 0 0 ? S< May17 0:00 [kworker/2:0H] root 21 0.0 0.0 0 0 ? S May17 0:00 [watchdog/3] root 22 0.0 0.0 0 0 ? S May17 0:01 [migration/3] root 23 0.0 0.0 0 0 ? S May17 0:00 [ksoftirqd/3] root 25 0.0 0.0 0 0 ? S< May17 0:00 [kworker/3:0H] root 26 0.0 0.0 0 0 ? S< May17 0:00 [khelper] root 27 0.0 0.0 0 0 ? S May17 0:00 [kdevtmpfs] root 28 0.0 0.0 0 0 ? S< May17 0:00 [netns] root 185 0.0 0.0 0 0 ? S< May17 0:00 [writeback] root 188 0.0 0.0 0 0 ? S< May17 0:00 [kintegrityd] root 189 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 190 0.0 0.0 0 0 ? S< May17 0:00 [crypto] root 192 0.0 0.0 0 0 ? S< May17 0:00 [kblockd] root 286 0.0 0.0 0 0 ? S< May17 0:00 [ata_sff] root 296 0.0 0.0 0 0 ? S< May17 0:00 [md] root 393 0.0 0.0 0 0 ? S< May17 0:00 [rpciod] root 394 0.0 0.0 0 0 ? S May17 0:00 [kworker/2:1] root 457 0.0 0.0 0 0 ? S May17 0:00 [khungtaskd] root 465 0.0 0.0 0 0 ? S< May17 0:00 [kswapd0] root 472 0.0 0.0 0 0 ? S May17 0:00 [fsnotify_mark] root 477 0.0 0.0 0 0 ? S< May17 0:00 [nfsiod] root 2888 0.0 0.0 0 0 ? S< May17 0:00 [iscsi_eh] root 2974 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_0] root 2987 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_1] root 2996 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_2] root 3006 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_3] root 3013 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_4] root 3025 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_5] root 3090 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_6] root 3099 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_7] root 3109 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_8] root 3119 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_9] root 3179 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_10] root 3189 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_11] root 3196 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_12] root 3208 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_13] root 4120 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_14] root 4133 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_15] root 4306 0.0 0.0 0 0 ? S< May17 0:00 [raid5wq] root 4571 0.0 0.0 0 0 ? S< May17 0:00 [deferwq] root 4725 0.0 0.0 0 0 ? S May17 0:00 [khubd] root 4729 0.0 0.0 0 0 ? S May17 0:00 [kethubd] root 5027 0.0 0.0 0 0 ? S< May17 0:00 [etxhci_wq7] root 5105 0.0 0.0 0 0 ? S< May17 0:01 [kworker/2:1H] root 5106 0.0 0.0 0 0 ? S< May17 0:01 [kworker/3:1H] root 5133 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 5134 0.0 0.0 0 0 ? S May17 0:03 [md0_raid1] root 5162 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 5163 0.0 0.0 0 0 ? S May17 0:00 [md1_raid1] root 5174 0.0 0.0 0 0 ? S< May17 0:01 [kworker/1:1H] root 5175 0.0 0.0 0 0 ? S< May17 0:01 [kworker/0:1H] root 5302 0.0 0.0 0 0 ? S< May17 0:00 [ext4-group-desc] root 5303 0.0 0.0 0 0 ? S May17 0:00 [jbd2/md0-8] root 5304 0.0 0.0 0 0 ? S< May17 0:00 [ext4-dio-unwrit] root 5329 0.0 0.0 0 0 ? S May17 0:01 [kworker/0:2] root 5353 0.0 0.0 17264 1460 ? Ss May17 0:00 /usr/bin/cgmanager --sigstop system 5418 0.1 0.1 967488 7652 ? Ssl May17 0:25 /usr/bin/syslog-ng -F --worker-threads=4 -u system -g log root 5441 0.0 0.0 0 0 ? S May17 0:01 [kworker/1:5] root 5895 0.0 0.0 0 0 ? S May17 0:00 [kworker/2:5] root 6458 0.0 0.0 0 0 ? S May17 0:00 [ecryptfs-kthrea] root 6573 0.0 0.0 17840 1192 ? Ss May17 0:00 udevd --daemon root 6586 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 9705 0.0 0.0 0 0 ? S< May17 0:00 [bond0] root 10965 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 10970 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 10971 0.0 0.0 0 0 ? S May17 0:00 [md5_raid1] root 10977 0.0 0.0 0 0 ? S May17 0:02 [md4_raid5] root 10980 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 10995 0.0 0.0 0 0 ? S May17 0:02 [md2_raid5] root 11150 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 11169 0.0 0.0 0 0 ? S May17 0:02 [md3_raid5] root 11576 0.0 0.0 0 0 ? S< May17 0:00 [kdmflush] root 11583 0.0 0.0 0 0 ? S< May17 0:00 [bioset] root 11769 0.0 0.0 6328 756 ? S May17 0:00 /usr/bin/inetd root 11811 0.0 0.0 86824 1696 ? Ss May17 0:00 /usr/bin/sshd root 12282 0.0 0.0 0 0 ? S< May17 0:00 [ext4-group-desc] root 13153 0.0 0.0 0 0 ? S May17 0:00 [jbd2/dm-0-8] root 13154 0.0 0.0 0 0 ? S< May17 0:00 [ext4-dio-unwrit] root 13472 0.0 0.0 0 0 ? S May17 0:00 [scsi_eh_16] root 13473 0.0 0.0 0 0 ? S May17 0:00 [usb-storage] root 13571 0.0 0.0 8576 760 ttyS0 Ss+ May17 0:00 /sbin/getty 115200 console root 15318 0.8 0.2 241756 9292 ? SLl May17 2:08 /usr/syno/sbin/synorelayd root 15706 0.0 0.0 0 0 ? S May17 0:01 [kworker/1:8] root 15707 0.0 0.0 0 0 ? S May17 0:01 [kworker/1:9] root 16127 0.0 0.1 1266364 6928 ? Ssl May17 0:03 /var/packages/MediaServer/target/sbin/dms root 16851 0.0 0.0 0 0 ? S May17 0:01 [kworker/0:5] root 27872 0.0 0.0 0 0 ? S May17 0:00 [kworker/0:3] root 28364 0.0 0.0 0 0 ? S May17 0:00 [kworker/u8:1] root 28392 0.0 0.2 179448 8600 ? Ss May17 0:00 sshd: admin [priv] root 28401 0.0 0.0 179448 2584 ? S May17 0:00 sshd: admin@pts/8 admin 28402 0.0 0.0 26064 2224 pts/8 Ss May17 0:00 -sh root 28427 0.0 0.0 44076 1760 pts/8 S May17 0:00 sudo -i root 28432 0.0 0.0 26108 2368 pts/8 S May17 0:00 -ash root 29765 0.0 0.0 0 0 ? S May17 0:00 [kworker/2:3] root 29767 0.0 0.0 0 0 ? S May17 0:00 [kworker/3:0] root 29768 0.0 0.0 0 0 ? S May17 0:00 [kworker/3:1] root 29778 0.0 0.0 0 0 ? S May17 0:00 [kworker/3:2] root 30565 0.0 0.0 0 0 ? S 00:08 0:00 [kworker/1:1] root 30604 0.0 0.0 0 0 ? S 00:15 0:00 [kworker/3:3] root 30620 0.0 0.0 0 0 ? S 00:24 0:00 [kworker/u8:2] root 30623 0.0 0.0 0 0 ? S 00:25 0:00 [kworker/0:1] root 30632 0.0 0.0 0 0 ? S 00:29 0:00 [kworker/1:0] root 30635 0.0 0.0 0 0 ? S 00:29 0:00 [kworker/u8:0] root 30636 0.0 0.0 0 0 ? S 00:29 0:00 [kworker/2:2] root 30637 0.0 0.0 0 0 ? S 00:29 0:00 [kworker/3:4] root 30780 0.0 0.0 27732 1476 pts/8 R+ 00:33 0:00 ps -aux

umount /dev/vg1000/lv umount: /dev/vg1000/lv: not mounted J'avais pensé à revérifier avant.

lvm pvscan PV /dev/md2 VG vg1000 lvm2 [19.96 TiB / 0 free] PV /dev/md3 VG vg1000 lvm2 [20.01 TiB / 0 free] PV /dev/md4 VG vg1000 lvm2 [20.01 TiB / 0 free] PV /dev/md5 VG vg1000 lvm2 [1.82 TiB / 0 free] Total: 4 [61.81 TiB] / in use: 4 [61.81 TiB] / in no VG: 0 [0 ] lvm vgscan Reading all physical volumes. This may take a while... Found volume group "vg1000" using metadata type lvm2 Premier souci à cette ligne lvm lvchange -ay Please give logical volume path(s) or use --select for selection. Run `lvchange --help' for more information. lvm lvscan ACTIVE '/dev/vg1000/lv' [61.81 TiB] inherit Second problème (et pourtant, j'ai bien cette fois passé les deux commandes données précédemment + tué les process qui pouvaient rester avec la commande kill - il n'y en avait qu'un au final et plus rien n’apparaissant la seconde fois après le kill). fsck.ext4 -vnf /dev/vg1000/lv e2fsck 1.42.6 (21-Sep-2012) Warning! /dev/vg1000/lv is in use. Warning: skipping journal recovery because doing a read-only filesystem check.

.J'ai réussi à passer syno_poweroff_task -d en changeant mon timer de déconnexion dans PuTTy de 0 à 60. Puis dans la console SSH, passer cette commande : for p in [0-9]*; do ls -l /proc/$p/fd ;done | grep volume pour chercher et killer les process qui seraient récalcitrants. Je ne sais pas comment faire pour utiliser le script suivant proposé par contre. for proc_pid in $(find /proc -maxdepth 1 -name "[0-9]*"); do \ ls -l ${proc_pid}/fd 2>/dev/null \ | grep -q volume \ && ps -q "${proc_pid#/proc/}"; \ done J'arrive à passer umount -f /volume1 pour démonter le volume. Mais quand je veux passer fsck.ext4 -vnf /dev/vg1000/lv, il me répond : Warning! /dev/vg1000/lv is in use. Et je ne vois pas ce qui pourrait encore bloquer après cette recherche de process à tuer. J'ai laissé la vérification en mode lecture seule pour cette nuit, afin de trouver si des inodes posent problème. La suite sera de trouver pourquoi le système me dit que le volume est toujours utilisé et tenter une réparation ultérieure (si possible). Je termine de sauvegarder le plus urgent entre temps. Merci en tout cas des réponses déjà données.

Pour cela que je venais vous voir, pas moyen de garder la connexion SSH (en mode root) en utilisant : syno_poweroff_task -d Je me fais éjecter en 30 secondes, et quand je me reconnecte de nouveau pour passer toujours en mode root : umount -l /volume1 puis vgchange -ay e2fsck -v -n -f /dev/vg1000/lv Le système me dit qu'il est encore utilisé, sans savoir ce qui est encore connecté au volume logique (n'ayant pas accès à la commande lsof sur mon NAS).. La dernière commande s'exécute quand même afin de procéder à la vérification sans écriture et me trouve une erreur d'inode à un moment (que je vous fournis après un édit dans la prochaine heure). Pour les backups, je n'en ai uniquement qu'une partie pour le moment. Je devais lancer une procédure de sauvegarde totale de ce NAS après cette expansion et acheter les disques manquants dans les prochaines semaines (besoin encore de 10 disques de 6 To à trouver et à peupler par la suite). Je suis déjà en train de procéder aux sauvegardes les plus vitales de ce soir (documents administratifs, photos de famille, contrats, carnet de contacts, BdD). Pour information, j'avais changé déjà un disque 6Tb par un 8Tb il y a environ 1 mois et l'erreur ne s'était pas présentée (d'où je suis étonné que l'on me parle d'un souci depuis janvier); je n'ai eu ce souci de message d'erreur de système de fichiers que depuis la demande d'expansion il y a 12 jours.

Pour la topologie. On part sur 10 disques en WD RED 6Tb (casiers 1 & 2, puis 5 à 12), ainsi que deux disques en WD RED 8Tb (casiers 3 & 4 - remplacement des 6Tb les plus vieux de la grappe par de nouveaux HDDs depuis début 2017). Ci-joint le résultat de MDSTAT et en pièce jointe un extract de la commande DMESG. Pour les logs, je ne sais pas lesquels sont pertinents à vous transmettre ou à regarder, car je ne suis pas du tout spécialiste dans le monde Linux. dmesg.txt

Souhaitant étendre le volume de mon NAS DS2413+ par le remplacement d'un WD RED 6To, par un modèle 8To de la même marque, impossible de pouvoir terminer l'extension après la vérification de cohérence de parité. DSM me signale des erreurs dans le fichier de fichiers et me propose de redémarrer pour effectuer une correction. - Volume statut NORMAL avant et après tentative de réparation. - Vérification SMART en mode long - HDDs OK sous DSM avant et après tentative de réparation. - Contrôle des HDDs individuellement sur une autre machine - 0 reconnexion et 0 bad block trouvé. Redémarrage + tentative de correction (environ 5H chaque tentative). Toujours même résultat avec un message de DSM concernant une erreur de système de fichiers. Tentative de réinstaller DSM en sortant 11 des 12 disques et en installant un spare dans le premier casier - DSM réinstallé, packages réinstallés et configuration remise. Tentative de réinitialiser le système au bouton reset, même message d'erreur de système de fichiers après tentative de réparation du volume. Même problème après installation du DSM 6.1.1-15101 Update 2 + 3ème tentative de réparation (toujours e2fsck+debugfs pendant environ 5H quand je monitore sous PuTTy). Données parfaitement accessibles si l'on ignore l'erreur et que l'on ne redémarre pas comme demandé dans l'interface de DSM. J'ai signalé le problème à l'assistance technique il y a désormais 10 jours ouvrés, sans réponse de leur part. J'ai écrit une relance il y a 2 jours afin de savoir ce que je devais faire ou me donner un statut de ma demande auprès du service, sans réponse à l'écriture de ces lignes.

Bonjour à toutes et à tous, trentenaire avec un DS2413+ de 12 disques de plus de 60Tb; utilisateur depuis plus de 3 années de cette machine. Je viens chercher des expériences d'autres utilisateurs, des astuces et éventuellement des petits conseils en dépannages. Merci à vous de m'accepter dans cette communauté.