marcmame

Tiens, un petit procès d'intention ! 1/ Bonjour, je m'appelle Marc et merci pour l'accueil chaleureux. 2/ Je découvre le site dans le cadre de mes recherches initiales sur ce problème, besoin qui ne s'était pas fait ressentir jusqu'ici. Mais il n'empêche que je trouve que c'est une mine d'infos interessante proposé par certaines personnes visiblement très qualifiés qui me sera probablement utile dans le futur. N'ayant pas ce niveau de connaissance, il me sera difficile de contribuer autrement que de manière relativement basique. C'est comme ça. Chacun est expert dans son domaine. 3/ Je ne me plains de rien. J'ai initié une question sur mon problème que quelques uns ont gentiment tenté de résoudre sans succès. 4/ Je reviens pour informer la communauté de l'existence de ce bug et remercier de l'aide apportée. Ce n'est étonnamment pas une démarche appréciée par tous ici. Dans mon domaine d'expertise, j'apprécie que les personnes que j'ai pu aider (ou pas) viennent partager la résolution de leurs problèmes et c'est finalement assez rare.

Permet moi de douter du fait que la majorité des utilisateurs passent par la case "white list" de syno avant d'acheter et fourrer des disques dans le NAS. Bah oui pourquoi pas ? Je le dis depuis le début : j'assume intégralement. Que puis-je en savoir ? En tout état de cause, vu le harcèlement effectué pour ne pas activer l'hibernation, les personnes concernées n'en sauront rien...

Ah mais non, le SSD joue son rôle et fonctionne parfaitement depuis près de 2 ans. C'est juste un bug du DSM qui empêche son hibernation. Et le choix a été fait en totale connaissance de cause et je ne blâme personne. Par contre, un bug ça se remonte et c'est ce que j'ai fait. Rien de plus. Et oui, le choix d'un matériel non testé par le fabricant se résume à de la loterie effectivement. Mais même les HDD listés doivent répondre à des références précises avec des firmwares précis. Il est extrêmement facile de tomber pile à coté.

J'assume totalement ma part de responsabilité, aucun soucis là dessus. Je remarque juste ce besoin de minimiser voir justifier la présence d'un bug reconnu par le constructeur lui même, comme si, au final, ce n'en était pas vraiment un... Je retrouve ces mêmes comportements sur les forums Apple avec certains fanboys. Qui veut noyer son chien l'accuse de la rage. 😉

Je comprend parfaitement les réticences que chacun peut avoir et on peut en parler durant des heures, mais je me permet de rappeler que le problème n'est PAS le SSD mais un bug dans le DSM...

Ah ben voilà des remarques qui font plaisir et qui font bien avancer le schmilblick. Ça fait chaud au coeur. Et pour ton information, Sabrent existe depuis plus de 20 ans et est une société Américaine plutôt reconnue (ailleurs que dans ton quartier) et leur garantie de 5 ans est plutôt un gage de fiabilité que l'inverse.. Au final je trouve assez savoureux de s'en prendre à cette marque alors que Synology reconnait un bug dans son code DSM. Bref... Et concernant l'hibernation, comment dire... Le sujet a été traité dès la première réponse, puis à la suivante... Pas certain d'avoir envie de me justifier à chaque fois et surtout pas pour m'entendre dire que ça réglerait le problème en plus de me sauver les disques, la vie et le climat probablement. Merci à ceux qui ont tenté de m'aider en tout cas.

Merci pour tes pistes niklos0 ! Le coupable a finalement été identifié : un bug dans la dernière version de DSM qui ne s'accommode plus avec mes SSD NVMe de marque Sabrent utilisés pour le cache. Depuis cette version, DSM fait une boucle infinie avec un message d'erreur pour tenter de récupérer le code vendeur des SSD. C'est cette boucle qui empêche le NAS de se mettre en hibernation. Obligation de les retirer physiquement pour retrouver un comportement normal. Vu que ces SSD ne font pas partie de la liste des modèles supportés, je n'ai pas d'autre choix que de les retirer en attendant un éventuel correctif de leur part, ce qui n'est même pas assuré. Bref, si vous utilisez des cache SSD NVMe qui ne font pas partie de la liste blanche de Synology, méfiance... 2021-05-01T17:45:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987 2021-05-01T17:46:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987 2021-05-01T17:46:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987 2021-05-01T17:47:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987 2021-05-01T17:47:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987 2021-05-01T17:48:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987 2021-05-01T17:48:40+02:00 NAS-32To-Marc synostoraged: nvme_disk_vender_get.c:47 Fail to get vendor name of 0x1987

Mon problème n'excite pas les foules on dirait ! Je suis en relation avec le support Syno depuis quelques jours et ce n'est pas plus brillant pour l'instant. Ce que je remarque dans les logs c'est que depuis cette mise à jour et au delà du fait qu'il ne passe plus en hibernation, il ne passe en mode inactif (Idle) que pour des périodes extrêmement courtes, jamais plus de 20 à 60 secondes d'affilé. C'est pour le moment inexplicable mais on comprend qu'il ne risque pas de passer en hibernation dans ces conditions... ======Idle 60 seconds====== Tue May 4 07:44:51 CEST 2021 ##################################################### ***********Clear********* [405388.501727] ppid:9458(synostoraged), pid:29747(sysctl), dirtied inode 12096967 (exe) on proc [405403.435495] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405403.435515] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405403.435518] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405463.449612] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405463.449632] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405463.449635] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405518.915987] ppid:9458(synostoraged), pid:30536(sysctl), dirtied inode 12095195 (exe) on proc [405523.464060] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405523.464079] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405523.464083] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405583.478015] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405583.478033] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405583.478036] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 uptime : [405589.607407] ======Idle 59 seconds====== Tue May 4 07:45:51 CEST 2021 ##################################################### ***********Clear********* [405463.449612] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405463.449632] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405463.449635] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405518.915987] ppid:9458(synostoraged), pid:30536(sysctl), dirtied inode 12095195 (exe) on proc [405523.464060] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405523.464079] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405523.464083] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405583.478015] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405583.478033] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405583.478036] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405643.492481] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405643.492501] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 [405643.492505] ppid:1(init), pid:28800(syslog-ng), dirtied inode 17560 (messages) on md0 uptime : [405649.604286] ======Idle 59 seconds====== Tue May 4 07:46:51 CEST 2021 ##################################################### ***********Clear*********

Malheureusement non. Juste la mise à jour DSM et rien d'autre. Rien de tout ça. Très peu de services actifs sur mon NAS. Et en l'occurrence le moniteur de ressources indiquent que tous les services sont en veille, exception faite du bureau DSM lorsque je m'y connecte pour vérifier. Bref, aucune activité anormale.

Admettons, sauf que : 1/ La surveillance de la connexion est toujours active, même en hibernation, c'est même le propos de l'hibernation, sinon autant l'éteindre... 2/ J'ai déconnecté justement parce qu'il ne se mettait plus en hibernation lorsqu'il était connecté. 3/ Mon NAS entrait parfaitement en hibernation avant cette mise à jour et que rien n'a été modifié entres temps.

Je vais le répéter encore une fois et on passe à autre chose ? Je sais parfaitement ce que cela implique mais je souhaite quand même utiliser cette fonctionnalité. Comment voir le log de mes I/O ? S'il s'agit des processus actifs du moniteur de ressources, seul le bureau DSM est réellement actif. En tout cas il n'y a rien d'anormal dans l'activité des services du NAS et je rappelle qu'il a passé la nuit déconnecté.

Je sais parfaitement ce que cela implique mais si on souhaite quand même l'utiliser, ça ne m'aide pas des masses... 😉

Bonjour, Après avoir fait cette mise à jour en 6.2.4-25556 sur DS1019+ il y a 48h, mon NAS ne passe plus en hibernation (réglé sur 20mn). J'ai tenté de débrancher le LAN cette nuit mais sans effet. Une idée pour résoudre ce problème ? Merci à vous.