Plantage complet DS1812+

[Lud]

Bonjour,

Pour la première fois depuis que j'ai des NAS Synology, mon DS1812+ s'est planté complètement hier soir. :(
Je précise que je ne suis pas chez moi pour un mois, avec une connexion Internet moisie (téléphone en hotspot wi-fi tout en haut de la maison à un endroit précis où ça capte à peu près la 3G ^^). Bref... :P

Matériel
NAS Synology DS1812+ avec 7 disques durs :
- 5 de 4 To en RAID 5 (tous passés par badblocks sans erreur)
- 2 de 2 To anciennement en JBOD, récupérés d'un ancien NAS, l'un des deux a commencé à me générer des erreurs depuis qu'ils sont en JBOD, alors que pendant des années en RAID 1, jamais de problème. Pareil pour un autre disque 1 To, a commencé à me générer des erreurs peu après l'avoir mis en JBOD (je l'ai sorti du Syno celui-ci), on ne m'y reprendra plus, plus jamais de JBOD chez moi.

Constat
Hier soir, plantage complet du NAS, impossible de se connecter en web, ssh, ftp ou autre, comme si tous les services s'étaient arrêtés d'un coup. J'ai constaté qu'il était encore allumé, puisqu'un telnet vers les ports que j'utilise habituellement (modifiés, mais qui correspondent au port d'admin, port ssh, etc) me renvoyait bien des ports ouverts. Mais pas de ping, de ssh, etc. Et la page web lorsque je tentait d'afficher ma page web d'admin me renvoyait une page Synology "Page non trouvée".
Bref, tout indiquait que le NAS était encore allumé, mais tous services éteints.

Circonstances
En fait, pas grand chose, comme j'avais des erreurs sur l'un de mes deux disques en JBOD, j'ai copié l'ensemble des données ailleurs, sauf certaines qui plantaient systématiquement ce volume lorsque j'essayais d'y toucher. Pareil si j'essayais de virer le dossier partagé qui les contiennent, impossible de le supprimer. Mais j'ai pu supprimer le volume JBOD créé sur ces deux disques.
Une fois fait, je me suis connecté en ssh, et en prévision de lancer un badblocks sur les deux disques en parallèle, j'ai commencé par virer les informations de partition avec un :
dd if=/dev/zero of=/dev/sdX bs=512 count=1
sur chacun des deux disques, puis une écriture de zéros sur les deux en même temps avec :
dd if=/dev/zero of=/dev/sdX bs=1M &
et c'est la seule chose qui était en cours au moment ou le NAS a planté.

J'ai demandé à un voisin qui a la clé de chez moi de redémarrer mon NAS, je ne doutais pas que tout repartirait sans souci au redémarrage. Effectivement tout paraît fonctionnel.

Logs
Peu après le redémarrage, j'ai récupéré le dossier /var/log/ sans trop savoir où chercher (je suis plus réseaux que système ^^).
Pour l'instant, le seul qui paraît à peu près intéressant est synoservice.log (plutôt verbeux d'ailleurs ^^). On voit que c'est la fête des services, qui s'arrêtent, démarrent, se mettent en pause, redémarrent, etc.
Tout commence par :
Aug  1 23:01:52 Syno scemd: service_third_party.c:87 synoservice: stop all packages with [volume] action ...
J'avoue que je ne sais même pas à quoi correspond le service_third_party.c:87.
Mais si une âme charitable veut bien me filer un coup de main pour trouver l'origine du problème (je n'ai pas trop envie que ça se reproduise :P ), je suis plus qu'intéressé !

Merci d'avance, et n'hésitez pas à demander d'autres infos si nécessaire ! ;)

[Edit]
Je suis en train de me dire que je n'ai pas redémarré le NAS après avoir supprimé le volume et lancé les commandes pour rincer les disques. Est-ce que ça pourrait venir de là ? Ça me surprendrait quand même...

Surtout que c'est un volume créé récemment, le principal a toujours été sur le volume 1.

En tout cas pour l'instant c'est l'explication la plus plausible. Le volume en question n'aurait pas été supprimé "proprement" par le DSM, et des adhérences de services seraient restées. Adhérences qui se sont senties mal lors de lorsque je leur ai écrit des zéros dessus. J'espère que ce n'est que ça, ça voudrait dire que ça ne se reproduira pas, et qu'il aurait suffit d'un reboot bien placé pour éviter les dégâts.

Modifié le 2 août 2016 par Lud

[Fenrir]

il y a 25 minutes, Lud a dit :

Je suis en train de me dire que je n'ai pas redémarré le NAS après avoir supprimé le volume et lancé les commandes pour rincer les disques. Est-ce que ça pourrait venir de là ? Ça me surprendrait quand même...

Ce n'est pas à exclure, en fait sur un syno, le système est installé sur TOUS les disques (dans ton cas il a fait un raid1 de 7 disques), idem pour la swap, si l'un des disques déconne sévèrement (ce qui semble le cas pour certains de tes disques) ou qu'il change "bizarrement" d'état en cours de route, par exemple en supprimant la table des partitions avec dd, le syno peut se très fortement ralentir, tellement que certains services ne répondent plus, en général il fini par déclarer le disque HS, mais parfois ça peut prendre des jours. De plus, un dd sur plusieurs To ça peut prendre du temps, bcp de temps, pendant ce temps là le syno prend cher, ce qui ne l'aide pas.

Perso, un disque qui présente ou a présenté un jour des signes de faiblesses, je ne le met plus jamais en service comme disque système, s'il n'est pas trop cuit, j'en fait éventuellement un disque de data (usb par exemple).

=>ce que tu devrais faire c'est retirer physiquement les disques suspects (attends peut être de rentrer pour le faire)

il y a 34 minutes, Lud a dit :

on ne m'y reprendra plus, plus jamais de JBOD chez moi

c'est pas faute de le crier sur les toits, le jbob c'est mal, le raid0 c'est pire

[Lud]

En fait le JBOD était bien pratique pour recycler des vieux disques pour du partage de torrents.

Je ne voulais surtout pas risquer de péter mon RAID5 en lui faisant écrire, modifier, déplacer supprimer des données à tour de bras. ^^

A l'avenir, j'utiliserais des volumes d'un seul disque pour éviter ce genre de mésaventure... Je voulais profiter de mes vacances pour balancer tous les badblocks nécessaires qui prennent trois plombes. ^^

Bien vu pour l'histoire du RAID1 de 7 disques pour le DSM. Pour une écriture de zéros telle que je l'ai faite, sur un disque dur de 2 To, je dois en avoir pour une heure, deux à tout casser, je n'ai pas vérifié, mais ce n'est pas si long. Rien à voir avec un badblocks par exemple. En plus, j'ai vérifié la consommation mémoire et CPU, qui est très faible. Et en mémoire, j'ai 3 Go, pas précisé plus haut, c'est vrai.

Concernant le fait de retirer les disques en erreur, je suis partagé. Dans l'absolu, tu as raison, mais je reste perplexe quand je vois que des disques qui n'ont jamais eu d'erreurs commencent à en avoir dès que je les utilise en JBOD. Les erreurs sont-elles réellement présentes ? Comment se fait-il que ce genre de choses arrive ? J'aimerais bien faire mon badblocks rapidement et voir ce qu'il me renvoie. C'est pour ça que j'aimerais bien le faire même si je ne suis pas encore rentré chez moi. ^^

Modifié le 2 août 2016 par Lud

[Fenrir]

il y a 9 minutes, Lud a dit :

A l'avenir, j'utiliserais des volumes de un seul disque pour éviter ce genre de mésaventure

ça ne changera rien au fait que DSM sera toujours installé sur tous les disques

il y a 9 minutes, Lud a dit :

sur un disque dur de 2 To, je dois en avoir pour une heure, deux à tout casser

sur un disque qui ne fait que ça, sans erreur, c'est possible, mais je te recommande de regarder le LOAD de ton syno lors d'une telle opération, en général, bien qu'il reste plein de ram et que le cpu se la coule douce, le load explose

-------------

il y a 10 minutes, Lud a dit :

je reste perplexe quand je vois que des disques qui n'ont jamais eu d'erreurs commencent à en avoir dès que je les utilise en JBOD

peut être que tu n'avais jamais écrit sur les secteurs endommagés avant

il y a 11 minutes, Lud a dit :

Les erreurs sont-elles réellement présentes

il faut tester les disques avec les outils du constructeur pour le savoir

Modifié le 2 août 2016 par Fenrir
réponse à une édition

[Lud]

il y a 1 minute, Fenrir a dit :

ça ne changera rien au fait que DSM sera toujours installé sur tous les disques

Effectivement, cela changera seulement quelque chose si c'est le fait d'avoir assemblé ces disques en JBOD qui est la cause des erreurs sur ces disques.

il y a 3 minutes, Fenrir a dit :

sur un disque qui ne fait que ça, sans erreur, c'est possible, mais je te recommande de regarder le LOAD de ton syno lors d'une telle opération, en général, bien qu'il reste plein de ram et que le cpu se la coule douce, le load explose

Je ne vois pas de quoi tu parles, pourrais-tu détailler à quoi correspond cette valeur et où la trouver ? Merci ;)

Effectivement pour la commande dd, je croyais qu'elle était terminée parce que je ne la voyais plus avec un "ps" en ssh, mais je la vois toujours via le moniteur de ressources du DSM.

[Fenrir]

https://en.wikipedia.org/wiki/Load_(computing)

[Lud]

Ah ok. Merci.

dd terminé donc je n'ai pas pu tester uptime dans ce contexte, mais je referai ça à l'occasion.

Il y a 7 heures, Fenrir a dit :

peut être que tu n'avais jamais écrit sur les secteurs endommagés avant

il faut tester les disques avec les outils du constructeur pour le savoir

Je n'avais pas vu que tu avais complété ton message.

Oui, effectivement. Je vais quand même faire un badblocks sur les deux disques, puis je testerai les outils constructeur.