Oooops!

Re-, alors les commandes et leurs résultats, par ordre chronologique de tes messages : 1) Syno209p> mdadm --detail /dev/md3 /dev/md3: Version : 1.2 Creation Time : Fri Mar 28 18:46:55 2014 Raid Level : raid0 Array Size : 1533820800 (1462.77 GiB 1570.63 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Fri Mar 28 18:46:55 2014 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64K Name : Syno209p:3 (local to host Syno209p) UUID : .../... Events : 0 Number Major Minor RaidDevice State 0 68 227 0 active sync /dev/sdca3 1 68 243 1 active sync /dev/sdcb3 pour le ".../...", je suis probablement parano mais je n'aime pas afficher des choses en rapport avec un "ID" (ici "UUID") dedans quand je ne sais pas de quoi il s'agit...? Une 'tite remarque au passage, par rapport à et ma réponse un peu plus bas: ici on voit apparaître en clair des "ioctets" 2) Syno209p> ls -la /volume2 drwxr-xr-x 3 root root 4096 Mar 30 14:44 . drwxr-xr-x 28 root root 4096 Mar 30 14:44 .. drwxrwxrwx 2 root root 4096 Mar 30 14:44 @tmp -rw------- 1 root root 6144 Mar 28 18:52 aquota.group -rw------- 1 root root 6144 Mar 28 18:52 aquota.user 3) -Système: Syno209p> mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Sat Jan 1 01:00:04 2000 Raid Level : raid1 Array Size : 2490176 (2.37 GiB 2.55 GB) Used Dev Size : 2490176 (2.37 GiB 2.55 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Sun Mar 30 15:14:44 2014 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : .../... Events : 0.315551 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/hda1 1 8 17 1 active sync /dev/sdb1 -swap: Syno209p> mdadm --detail /dev/md1 /dev/md1: Version : 0.90 Creation Time : Sat Jan 1 01:00:04 2000 Raid Level : raid1 Array Size : 2097088 (2048.28 MiB 2147.42 MB) Used Dev Size : 2097088 (2048.28 MiB 2147.42 MB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Fri Mar 28 18:51:51 2014 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : .../... Events : 0.20 Number Major Minor RaidDevice State 0 8 2 0 active sync /dev/sda2 1 8 18 1 active sync /dev/sdb2

Bonjour, euh, pour ma part je n'appellerais pas ça une arnaque mais un manque de rigueur des "concepteurs" (au sens large). les fabricants de disques ont décidé de compter en base 10, c'est leur droit (kilo = x1000, mega= x1000000, etc) car ça correspond bien aux normes internationales de préfixes d'unités. par contre ces sont les fabricant d'OS qui n'appliquent pas les normes: pour régler cet épineux problème, connu depuis aussi longtemps que les disquettes mais moins "visible" à cause des valeurs disponibles à l'époque, une norme a été créée en 1998 par l'IEC, mentionnant que le kilo = x1024, méga = 1024x1024, etc, même en utilisant une majuscules à "octet" au lieu d'une minuscule, n'était pas normal => on doit dans ce cas parler en "ioctets" ou plutôt les multiples: 1kio = 1024 octets, 1Mio = 1048576 octets, etc. 4To = 3,63Tio; ça fait plus de 15 ans déjà... Le plus bête dans le cas de Synology c'est que je jurerais (j'emploie le conditionnel car je n'ai pas gardé de copie d'écran qui le montre) que dans une version antérieure DSM affichait bien le "i", par exemple j'avais vu dans le Gestionnaire de stockage que mes 2 disques 3To en Raid1 me donnaient un volume de 2,73Tio. Pour information, cf par exemple http://fr.wikipedia.org/wiki/Octet À noter le manque de rigueur, ou même plutôt la co....ie de certains professionnels qui n'osent pas employer les termes justes, soi-disant par peur de dérouter le grand-public alors qu'ils ne font que contribuer à entretenir la confusion, exemple Windows qui depuis la version 95 emploie "Résolution" à la place de "Définition" dans certains paramètres (ex le bureau, les écrans) alors qu'il l'emploie correctement -donc c'est incohérent- dans d'autres (ex les propriétés d'un fichier graphique)...

Bonjour, ça ne récupère pas absolument tout (=> cf l'aide dans DSM pour avoir la liste exacte), mais il y dans DSM une commande permettant de sauvegarder la configuration du NAS. Par contre comme je suis en DSM 4.2 et toi probablement avec une version plus récente je ne pourrai pas te dire où elle se trouve, mais d'inciter à lire la doc de DSM5 et surtout l'aide intégrée à DSM (habituellement très/plus complète que le PDF). [Edit] Je viens de voir sur le même sujet => ouvrir plusieurs topics pour évoquer le même problème ne me semble pas le meilleur moyen d'avoir des réponses utiles... [Fin Edit]

Bonjour, j'étais quasiment sûr que ça te ferait réagir ! Syno209p> df -h Filesystem Size Used Available Use% Mounted on /dev/md0 2.3G 450.9M 1.8G 20% / /tmp 251.7M 340.0K 251.4M 0% /tmp /dev/md2 3.6T 3.2T 409.1G 89% /volume1 /dev/md3 1.4T 197.2M 1.4T 0% /volume2 Je ne suis pas sûr de comprendre comment relier ces résultats aux disques qui sont dans le Syno: 2 disques de 4To en Raid1 classique => d'après le Gestionnaire de stockage, mon "Volume 1" de de 3,56Tio, dont 409,12Gio disponibles => c'est "md2" 1 disque de 80Go + 1 de 1,5To en Raid0-Syno => d'après le Gestionnaire de stockage, mon "Volume 2" de de 1,41 vide (donc pourquoi 197,2Mo utilisé, c'est pour sa gestion de fichiers, comme quand on formate un disque?) => c'est "md3" => "md0" est la partition système et "temp" est la partition de swap, et toutes les 2 sont dupliquées sur les 4 disques? C'est DSM qui "transpose" le nom "Volume 1" en "nom Linux" "volume1"? (ou plutôt, l'inverse? et idem bien-sûr pour "Volume 2") Syno209p> mount | grep /volume2 /dev/md3 on /volume2 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl) Syno209p> fdisk -l /dev/hd? 2> /dev/null Disk /dev/hda: 2199.0 GB, 2199023255040 bytes 255 heads, 63 sectors/track, 267349 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 267350 2147483647+ ee EFI GPT Disk /dev/hdb: 2199.0 GB, 2199023255040 bytes 255 heads, 63 sectors/track, 267349 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 1 267350 2147483647+ ee EFI GPT Là, j'ai l'impression que la commande est trompée par le fait que les 2 disques internes du DS sont des 4To, donc supérieurs aux classiques 2,2To. Par contre, pourquoi les 2 disques du DX n'apparaissent-ils pas ici? Remaque à propos de "Il y a de fortes chances que ce soit un LVM et que la mention RAID0 ne soit devenue qu'une etiquette.": j'ai pensé la même chose (en moins précis car je ne connais pas assez bien Linux et en particuler les LVM ), mais si c'est ça, je ne sais pas d'où vient cette spécificité (version de DSM ou tailles différentes des disques), car en DSM2.3, puis en DSM3.2 (alors que là le SHR existait déjà chez Syno) j'avais fait un Raid0 dans mon DS211J, et au vu de la perte de performance quand je l'ai passé en Raid1 je crois que ce Raid0-là était un "vrai" Raid0; certes je l'ai fait sur de nouveaux disques et avec une autre version de DSM, mais je ne crois pas que ces 2 facteurs justifieraient la très nette baisse constatée des performances en écriture (env 60Mo/s en Raid0 -disques 1,5To/DSM3.2- et 45Mo/s en Raid1 -disques 4To/DSM4.2-). [Edit] Je pense que la suite des tests sera de faire un JBOD, puis de refaire un Raid0 mais avec 2 disques de 1,5To (et idem en JBOD)? [Fin Edit]

Bonjour, 1) le PopCorn et l'AppleTV font fonction de "boîtier multimédia" => ta première phrase "Je ne pense pas utiliser de boitier multimédia dans un premier temps" veut-elle dire que tu ne veux plus les utiliser? Si c'est ça, là *peut-être* que le 214Play se justifie pour toi. 2) j'ai un peu de mal à m'y retrouver dans la gamme Seagate, car mis à part le fait que l'un est un 7200tr/mn et les 2 autres des 5900tr/mn, je ne vois pas de différence évidente entre les 3 (le 3ème, pas dans ta liste, est le Seagate NAS -ST2000VN000-) => il faudrait éplucher de près toutes les caractéristiques tecniques (et commerciale, ex garantie) sur le site du fabricant, mais c'est pas commode car ils sont classés dans des familles différentes. À noter que le VN est reconnu comme compatible pour toute la gamme (càd toutes les capacités) sur le site de Synology, alors que le VM est OK pour une révision (mais ça ne veut pas dire qu'il y en a d'autres) et le VX n'apparaît que en 3To; même si ça ne veut pas forcément dire que le 2To ne fonctionnera pas, c'est celui que je mettrais en dernier dans les préférences; après, entre le VM et le VN, je ne sais pas (j'ai 2 VN en 4To, RAS).

Bonjour, à tout hasard: avez-vous, tous les deux, essayé de rebooter le NAS après modifcation du paramètre d'hibernation?

Re-, je peux me tromper, mais je crois que ton cas ressemble bien à celui de Selujuntu: les valeurs 4, 12 et 193 sont certes assez éloignées de zéro mais pas du tout critiques, d'autant plus qu'elles sont probablement dûes à l'utilisation de l'hibernation; inversement si ton disque faisait partie de ceux à problèmes de LLC, je pense que le ID 193 serait beaucoup plus élevé, surtout depuis janvier 2013. Remarque: il me semble avoir remarqué que le pb de LLC sur des RED n'est arrivé que bien après leur lancement (peut-être une modif en production) et que les premiers n'avaient pas ce souci (bon, ils en avaient d'autres, mais c'est une autre histoire et là aussi, s'ils fonctionnent normalement aujourd'hui il est plus que probable que tu sois passé à côté de ces problèmes-là aussi ).

Bonsoir, d'après la page de support de WD la procédure est possible sous Linux, mais je ne sais pas si ça passerait en ligne de commande sur le NAS, et jusqu'à maintenant je n'ai lu des messages que de gens qui avaient fait la manip en mettant le disque dans un PC.

Bonsoir, bon, il n'y a pas d'erreur dans le Comparateur de Raid, le Raid0 de Synology additionne bien l'intégralité de la capacité des disques, mêmes s'ils sont de taille différente; les détails dans .

De rien; mais je soupçonne que tu vas quand même avoir quelques tests en ligne de commande à me demander, quand tu auras lu .

Bonsoir, comme la très grande majorité d'entre vous je crois, j'en étais resté à l'idée que quand on fait un Raid0 avec 2 disques de taille différente, la capacité du volume obtenu est égale à 2 fois la taille du plus petit des 2 disques (on en a encore parlé tout récemment ). C'est aussi ce que j'ai vu sur tous les sites que j'ai consultés sur internet; ou presque, car celui-ci indique bien: mais juste en dessous Dans le message que j'ai mis en lien au début, j'avais signalé que le comparateur de Raid du site Syno avait un bug, puisque pour un disque de 640Go + un de 2To, en Raid0 il indique 2,6Go de capacité, et pas 1,2Go (2x640Mo), et qu'il faudrait le signaler à Synology. J'ai donc utilisé la rubrique "Contactez-nous", "Commentaire sur le site web", pour signaler la chose, en indiquant aussi que Synology lui même, dans ce tutorial, appliquait bien la règle habituelle (2 x capacité du plus petit disque). J'ai très vite reçu une réponse de Synology indiquant que effectivement il y avait une erreur et qu'elle allait être corrigée très vite; mais encore plus vite (moins de 5h) le rectificatif suivant (j'espère que l'auteur ne m'en voudra pas de copier/coller une partie de son message sans lui en avoir demandé l'autorisation avant ): Un peu dubitatif, j'ai répondu en fin d'après-midi en insistant (confusion éventuelle entre Raid0 et JBOD?) et surtout en demandant comment cela était possible avec le principe de stripping du Raid0 ; mais là c'est le weekend et je vais probablement devoir attendre la réponse un peu plus longtemps. En attendant, comme j'en avais la possibilité, j'ai décidé de tester avec 1 disque de 80Go + 1 disque de 1,5To montés dans le DX213 connecté à mon DS209+II, et effectivement ça fonctionne comme indiqué: chez Syno, le RAID0 additionne la capacité des disques, même s'ils sont de taille différente, cf la copie d'écran ci-dessous:

Bonsoir, si tu es en interface graphique avec FileStation, oui c'est ça; mais pas des disques, des dossiers partagés des volumes.

Bonjour, bon, bin je crois que les tests ne vont pas aller très loin, car je n'arrive pas à installer DSM sur un disque mis dans le DX avec le DS vide: ça commence normalement, SynoAssistant voit le NAS sur le réseau, comme non-installé, et propose automatiquement d'installer DSM (demande de fichier .pat) je sélectionne le bon fichier .pat, préalablement rapatrié en local => la procédure commence normalement (demande de création de mdp admin, choix d'adresse IP) mais après ça coince avec une erreur 38, cf copie d'écran: J'ai essayé de changer de baie, de changer de disque, d'utiliser l'installation automatique (en gardant les paramètres par défaut) et l'installation manuelle (avec les paramètres utilisés dans l'installation des disques du DS), rien à faire ça se termine toujours par l'écran dont j'ai mis la copie. Donc sauf si quelqu'un a une (bonne) idée à propos de cette erreur 38, l'expérimentation sur le DX va s'arrêter là. Remarque: d'une certaine façon, ça peut paraître assez normal que ça ne fonctionne pas, car si c'était OK la limite de compatibilité (impossibilité, sauf sur quelques modèles spécifiques, d'étendre un volume interne de DS sur un DX) n'existerait pas; or le DS209 ne figure pas dans la liste de compatibilité.

Bonjour, puisque tu n'as pas de PC pour éventuellement faire la màj de FW, si ça peut te rassurer je *crois* que tes disques ne sont pas concernés par la question du LLC qui augmente de manière anormale: si j'en crois ce qu'on lit sur divers forums, comme par exemple ce topic, les disques concernés voient leur LLC augmenter beaucoup par jour (de 200 à 1200); or tes valeurs sont très très inférieures. PS: pour la question des valeurs qui augment alors que l'hibernation est désactivée c'est effectivement un peu curieux car chez moi ça ne bouge plus; peut-être essayer de rebooter DSM?

Bonsoir, pour la duplication entre mes NAS j'ai utilisé 2 moyens cet été: - Passer par FileStation de l'un des 2 NAS: y monter le(s) dossier(s) partagé(s) de l'autre NAS et lancer les copies à partir du navigateur de fichiers de FileStation. - Ou alors depuis un PC sous Windows utiliser (en fenêtre DOS) RoboCopy en ligne de commande. Si on veut conserver les attributs, en particulier d'horodatage, des fichiers et répertoires, la première méthode est la plus simple; la 2ème est un poil plus performante, mais nettement plus compliqué à paramétrer.

Bonsoir, 1) pas sûr que tu aies besoin de la fonction transcodage, puisque le PopCorn et l'Apple TV3 le font déjà? 2) je ne crois pas que le streaming, même en 1080p, demande tellement de bande passante: sauf erreur de ma part un flux vidéo en 2D ne dépasse pas 6,5Mo/s => même pour alimenter 2 lecteurs en même temps un petit NAS peut suffire; mais connecté en filaire gigabit, car en CPL -et pire encore, en wifi- la transmission peut être le facteur limitant, plus que le NAS lui-même. 3) quel rapport entre l'USB3 et le port gigabit? certains gros modèles mis à part, je n'ai pas vu beaucoup de disque USB3 atteindre en pratique les 100Mo/s, alors qu'en gigabit sur les syno actuels ces valeurs sont assez souvent atteintes (et même dépassées, en lecture); de toute façon, si c'est la question du streaming vidéo qui là aussi t'inquiète, je te renvoie à ma réponse précédente; il faut savoir qu'un certain nombre de passerelles vidéo étaient encore en 100méga il y a peu de temps et que ça n'entravait nullement leurs performances en lecture. Remarque: je n'ai répondu que par rapport aux usages que tu indiquais (flux vidéo), par contre d'autres critères (et d'autres usages) peuvent déterminer le choix d'un modèle plutôt qu'un autre.

Bonsoir, content que tu aies pu régler la partie la plus importante du problème. Pour ce qui est du SAV Syno, regarde dans la page "Contactez-nous" du site pour voir s'il n'y a pas un service qui correspond à ce que tu cherches.

Bonsoir, 1) 3600 = 24heures x 30jours x 5mois = env le nb d'heures écoulées en 5 mois; à comparer aux seulement 925h de fonctionnement des disques durs. 2) les valeurs par défaut, ça dépend d'un usage "moyen" envisagé par le concepteur; mais chacun a son usage, pas forcément correspondant au schéma-type du concepteur du logiciel. Par ailleurs, ce n'est pas "se mettre en hibernation toutes les 3H en gros", c'est qu'il attend 3h pour passer en hibernation; mais s'il y a ne serait-ce qu'un seul accès toutes les 2h59, il ne passera jamais en hibernation. Ce paramètre 3H convenait bien à mes usages: en général pas de passage en hibernation pendant la journée car j'avais souvent des accès plus fréquents que toutes les 3h, par contre une période de repos d'environ 5h -8h de sommeil à partir du dernier accès moins les 3h avant hibernation- la nuit, et certains jours une autre période de repos, plus longue, quand je partais à l'extérieur bosser pour la journée. => C'est donc à chacun d'estimer le paramètre le plus adapté à ses usages (pour vos usages familiaux un paramètre un peu plus court serait peut-être envisageable) pour trouver le meilleur compromis entre disponibilité immédiate du NAS, faible nombre de entrée/sortie en hibernation, et nombre total d'heures de mise sous tension. 3) je n'en suis pas sûr, amis il est possible que le +1 corresponde simplement au fait que désactiver l'hibernation a réveillé les disques et enclenché un cycle donc un de plus comptabilisé; en fait ce qu'il sera intéressant de comparer, c'est l'évolution journalière ou hebdomadaire (actuellement, sur 5 mois d'usage il y a eu environ 750 cycles, donc en moyenne 5 par jours). 4) pour la màj de FW, je croyais avoir lu un message signalant les n° de série des disques concernés, mais je ne le retrouve pas donc je confonds peut-être avec un autre modèle de disque. Par contre je peux répondre à la suite de la question: dans le Gestionnaire de stockage > onglet "Gestion HDD" > cliquer sur un disque puis sur "Info du disque", on trouve toute l'identité du disque, en particulier n° de série et version de FW. Du moins en version 4.2; je ne connais pas la version 5.0, mais d'après son manuel je crois que les onglets de la version 4 sont le bandeau vertical à gauche de la fenêtre (cf p 23 du manuel, je crois que "HDD/SSD" = onglet "Gestion HDD" de DSM4).

Bonsoir, je ne sais pas si le test est significatif, mais apparemment la barrette PC2-667 est plus rapide que la PC2-800 d'origine (cf le topic spécifique ""); je n'ai toujours pas constaté de dysfonctionnement. Effectivement si la barrette est sur-cadencée elle pourrait vieillir/griller prématurément, mais inversement je me demande si l'origine n'est pas "sur-dosée" par rapport aux besoins réels (cf PC2-533 d'origine constructeur sur ordi à 1,6GHz). Je crois que je vais remettre la nouvelle barrette dans le Syno (je l'avais enlevée pour tester l'origine) et je verrai bien à l'usage...

- Marque: Kingston - Référence: KVR667D2S5/2G - Caractéristiques: 200-broches DDR2-667 PC2-5300 SO-DIMM CL5 (compatible DDR2-533 (dans eeePC901)) - Taille: 2 Go - Modèle du NAS: DS411+II - Compatibilité: OUI, apparemment (*) - Prix : environ 25€ actuellement, mais récupérée dans mes stocks... Je plagie honteusement ce que Fravadona avait fort bien fait dans son message : Test rapide (copie memoire de quelques Gigas par blocks de 1Mo, 512Mo et 1Go) : Bien qu'elle soit plus lente que l'origine (PC2-667 vs PC2-800), la barrette de remplacement semble donner de meilleurs résultats que l'origine. Pour le 3ème cas j'ai laissé toutes les valeurs retournées par la commande à cause de la bizarrerie "26,03=0,00+6,95" mais là aussi je suppose que c'est la question du cache évoquée par Fravadonna dans son rapport qui en est la cause? (*) installée depuis seulement quelques jours (récup dans mes stocks) elle est théoriquement trop lente mais pour le moment apparemment il n'y a rien d'anormal dans le fonctionnement du Syno. PS Fravadona: pour le tests mémoire, effectivement en allant dans les réglages avancés de SynoAssistant j'ai pu l'activer, mais à la fin le syno a simplement rebooté (comme annoncé au début du test) => je ne sais pas si/où les résultats sont enregistrés.

Re-, 1) puisque le NAS a été sous tension presque tout le temps (sauf les vacances) je crois que c'est bien l'hibernation qui explique la différence entre 3600 et 925. 2) comme l'hibernation système a été intoduite sur quelques modèles de la gamme "13", je pensais qu'elle existait sur tous les modèles ultérieurs, donc au moins ceux de la gamme "14"; or il semble que ça ne soit pas le cas et que cette fonctionnalité n'existe que sur 2 NAS de 2013, les DS213+ et DS413. Donc il serait normal que tu n'aies trouvé que la "classique" hibernation du disque dur montrée dans ta copie d'écran. 2 liens intéressants pour en savoir plus: http://www.synology.com/fr-fr/support/faq/568 et http://www.synology.com/fr-fr/support/faq/557 3) les valeurs SMART à surveiller les plus importantes sont à mon avis - pour l'état du disque (ce n'est pas la question ici, mais bon...): ID 5 et ID 197; ainsi que 1, 196 et 198, mais je crois que pour les 2 dernières c'est relaivement rare, et pour la première on s'en rend vite compte. - pour le fonctionnement du disque: celles que j'ai indiquées dans mon message précédent. Mais attention, là c'est l'évolution qu'il faut voir plus que les valeurs elles-mêmes: * le nb d'heures de mise sous tension (ID 9) va forcément augmenter plus -et de manière a priori linéaire- maintenant sans l'hibernation; * par contre les valeurs 4, 12 et 193 ne devraient plus beaucoup bouger -peut-être quelques unités, voire pas du tout- (c'est la dernière qui est concernée par la màj de firmware du disque). PS à propos de l'hibernation des disques (ce n'est que mon avis, et pas un conseil ;-)): La majorité des gens ici pourfendent l'hibernation des disques, pour des raisons "matérielles" et "logicielles"; pour ma part je suis plus réservé et je me dis -peut-être a tort- que Synology n'aurait pas pris le risque d'implémenter cette fonction si elle était aussi risquée. 1) sur le plan matériel: bien sûr qu'un appareil électrique souffre le plus au moment de sa mise sous tension et hors tension; mais inversement un fonctionnement continu est aussi la cause d'une usure => amha on peut envisager des compromis: de mon temps on avait coutume de considérer qu'un cycle allumage-extinction sur un appareil électrique/électronique (pas seulement les disques durs) "équivalait" à 3h de durée de vie. Je ne sais pas ce qu'il en est de ces "statistiques" aujourd'hui, mais il me semble que si, par exemple, on n'utilise pas son NAS la nuit, le fait que le disque dur hiberne 8h (donc fasse un cycle hors/sous tension en plus) est plutôt mieux que 8h de fonctionnement. Quand je l'utilisais, l'hibernation était réglée longue (genre délai de 2-3h, pour éviter les mises en hibernation inutiles), mais cette année mes usages sont devenus trop fréquents et irréguliers pour que je conserve l'hibernation activée. À noter qu'un utilisateur a signalé que dans sa boîte les serveurs qui étaient arrêtés plusieurs fois par an (je ne me souviens plus si c'était une fois par trimestre ou par mois) redémarraient toujours sans souci, alors qu'au contraire ceux qui tournaient en permanence refusaient parfois de re-démarrer. 2) sur le plan logiciel: le principal risque est que les disques redémarrent trop lentement pour être opérationnels et que DSM les considère comme en panne et les éjecte du Raid. Ça ne m'est jamais arrivé, quand j'utilsais de simple disques Green, et maintenant que les disques NAS (WD Red et Segate NAS) sont justement conçus -c'est du moins ce que disent leurs fabricants- pour répondre "présent" aux demandes du système (ici, DSM), il me semble que ce risque est écarté.

Re-, merci pour les infos, dont la première semble un peu "curieuse" (ou incomplète), et les autres cohérentes entre elles: 1) si le NAS a 5 mois, ça fait environ 3600 heures; or on voit un temps de fonctionnement (ID 9) d'env 925h => ça veut dire que le NAS n'est pas sous tension en permanence? Donc en plus de tes 5 reboot il y aurait plusieurs mise sous/hors tension? 2) si le NAS est toujours sous tension (ou presque, càd peu de mises sous/hors tension faites par toi), il est possible/probable que c'est l'hibernation(*) qui soit l'explication de ce faible nombre d'heures de mise sous tension des disques, du relativement grand nombre total de cycles marche/arrêt complets des disques durs (ID 12), ainsi que du nombre encore plus grand de cycles de mise en rotation (démarrage/arrêt, ID 4), lui-même en accord avec le nombre de parcage de têtes (ID 193). (*) au fait, de quelle hibernation parles-tu?: - sur mes Syno, un peu anciens (209-211-411), la seule hibernation est celle qu'on peut activer pour les disques durs; - sur des syno plus récents, dont le tien fait peut-être partie (?) il y a la possibilité d'une hibernation du système lui-même. => Amha, maintenant que tu as désactivé l'hibernation tu devrais regarder ces valeurs dans quelques jours pour voir comment elles ont évolué, je crois que ça sera un bon indicateur; même si je pense que a priori tes disques ne sont pas concernés car dans les messages où des forumeurs avaient remarqué le problème les valeurs de LLC (ID 193) les valeurs étaient bien plus élevées dans un laps de temps court. PS un tableau intéressant ici: https://fr.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology

Re-, il faudrait donc que tu répondes là-bas aux questions que j'ai posées , car si certaines valeurs peuvent paraître élevées, elles ne sont pas forcément anormales.

Bonjour, tu ne devrais pas poster la même question, différente du sujet initial, en double ici et dans un autre topic, ça ne facilite pas les choses => je t'ai répondu car le sujet était plus adapté (et que c'est là que j'ai d'abord vu cette autre question).

Re-, tu as raison, j'avais oublié qu'en Raid0 aussi on se base sur le plus petit disque; mais j'ai été induit en erreur par la page "Comparateur de Raid" du site Syno, qui indique 2,6Go pour un Raid0 avec 2G0 + 600Mo. Ça doit être une confusion avec le JBOD, car dans cette autre page du site Syno le tableau indique bien, pour le Raid0 "Capacité du volume: N x (taille du disque dur le plus petit)" (comme dans tous les sites qui parlent de Raid) => va falloir signaler à Synology qu'il y a une erreur dans le fonctionnement du "Comparateur de Raid"