StéphanH

J’ai ce genre de comportement uniquement avec les fichiers de la suite bureautique d’Apple (Numbers, Pages, Keynote) qui, lorsqu’ils sont ouverts, s’enregistrent fréquemment, générant une synchro drive. Il arrive que cela génère un fichier .conflict, mais cela reste rare.

Désolé @Lelolo Il semble toutefois que la 7.3, objet de ce sujet ne soit pas étrangère à la levée de cette limitation qui nous gêne tous ici … La presse semble en tous cas le dire.

Cette 7.3 assouplit la validation des disques ? Synology revient sur sa décision ??? https://itdaily.fr/nouvelles/logiciel/synology-dsm-7-3/

Moi qui pensait naïvement que SMART était normalisé 🙂 Mais surtout, je pense qu'avec des log "Le Disque 1 met du temps à répondre (je n'ai pas le libellé exact du message en tête)", ET une augmentation soudaine du nombre de secteurs défectueux, ET des services qui tombent (déconnexion VPN, …), le système a suffisamment d'éléments pour - à minima - prévenir l'utilisateur qu'il y a potentiellement une situation anormale à investiguer ... Ne rien dire a pour moi été une source de confusion : j'ai pensé naïvement que le problème venait soit de HomeBridge soit de Plex (qui sont les deux seuls softs non officiels que j'utilise). J'ai certes manqué d'expérience sur ce sujet … mais m'alerter m'aurait évité de passer beaucoup de temps à essayer de comprendre une surconsommation CPU qui n'existait pas ...

Merci @Mic13710 Je suis dubitatif. Les disques étaient considérés comme sains. Tout au plus, après un smart étendu, le disque 1 était considéré comme "à surveiller", sans plus de précaution. Je veux bien comprendre que cela soit courant, mais ce n'est pas parce qu'un problème est courant qu'il doit être toléré sans action. Tout de suite après détection du problème, que ce soit toi ou le support, vous avez réalisé en ligne de commande (ou suggéré de le faire) un test me permettant d'afficher le détail des résultat du SMART. Si DSM n'est pas capable d'analyser automatiquement le résultat de ces tests, ne devraient-ils pas prévoir un système d'aide au diagnostic, déclenché par l'administrateur, qui enchainerait les tests de base du système et des disques afin de cibler un éventuel problème ? Sinon, à l'heure de l'IA, et vu que le problème est courant, il doit y avoir de la matière pour entraîner un moteur de LLM qui aidera ensuite l'utilisateur dans ses investigations... Je serai curieux de savoir ce que proposent QNAP et les autres dans la détection d'incidents...

Oui merci @Lelolo J'ai reçu mon disque plus tôt que prévu. Le volume est en cours de reconstruction : durée estimée : 24h Le support Synology, dans sa réponse toute faite, ne trouve pas anormal le comportement que j'ai vécu. Je vous mets ici leur réponse pré-formatée : À propos du disque non détecté comme défectueux : Un état 'sain' indiqué par votre NAS ne garantit pas l'absence totale de problèmes. Les disques durs, y compris les modèles Western digital, Seagate et autres marques, sont validés selon des seuils de tolérance qui acceptent un certain nombre de secteurs défectueux. De plus, pour obtenir des données SMART réellement fiables, il est essentiel de procéder régulièrement à des tests complets. Sans ces tests approfondis, les informations affichées risquent d'être incomplètes ou ne pas refléter la santé réelle du disque. Concernant le blocage complet du système : La redondance du RAID est conçue pour prendre le relais lorsqu'un disque est totalement défaillant et retiré du raid. Cependant, tant que le disque défectueux reste inclus dans le système de stockage, le NAS continue de tenter d'y accéder. Cette persistance d'accès à un disque en panne peut entraîner des ralentissements importants, voire un blocage complet du système, car les opérations de lecture/écriture rencontrent des timeouts répétés. Sur la non-éjection automatique : Le système de surveillance des disques fonctionne sur la base de seuils prédéfinis. Si un disque présente des erreurs mais n'atteint pas le seuil critique configuré, il ne sera pas automatiquement éjecté. Cette conception vise à éviter des éjections intempestives, mais peut dans certains cas maintenir en service un disque partiellement défaillant, avec pour conséquence une dégradation des performances de l'ensemble du système.

Voici quelques news ... Avec la bénédiction du support, j'ai proposé d'extraire le disque 1 du NAS. J'ai donc utilisé le bouton beu pour éteindre le NAS (l'arrêt a duré plus d'une heure). J'ai alors extrait le disque 1 et ai rebooté. Le boot a été normal, suivi des bits persistants signalant un volume dégradé (normal, il manque 1 disque). Pour l'instant, le système fonctionne normalement, malgré un avis d'arrêt brutal que je ne m'explique pas J'attends un disque neuf d'ici 2 à 3 jours ...

Tu as très probablement raison, et je viens de passer commande. je trouve toutefois anormal que DSM considère que le volume est sain, que les disques sont sains, et qu’il faut juste surveiller le disque 1 . je suis curieux de voir la réponse du soutien demain …

Après une défragmentation, une récupération de l’espace disponible et un test SMART étendu, les deux disques sont affichés comme sains, avec un avertissement sur le disque 1 « disque à surveiller » je constate l’apparition de secteurs défectueux sur le disque 1 pour moi, celle-à ne justifie en rien un système injoignable, comme c’est le cas à nouveau ce matin…

Cela signifie que WD n’implémente pas les tests smart ? Il me semble pourtant que cela fonctionnait avant (j’avais des WD 3To dans mes DSx12+) jai quand même un doute quand tu écris : Je viens de saisir la commande sur mon disque 1 de mon côté, j’ai entré : sudo smartctl --all /dev/sda comme suggéré par Mic13710 sans préciser autre chose. je viens de trouver cela dans les logs. Étonnant que cela ne soit pas considéré comme un message critique nécessitant un mail ou un push … par ailleurs, le système oscille entre un état stable (depuis 1 heure, le NAS fonctionne nominalement, malgré l’opération en cours sur le volume, alors qu’après déjeuner, il était injoignable. Étrange …

Merci @Mic13710 J’ai dû rater quelque chose … smartctl 6.5 (build date Sep 26 2022) [x86_64-linux-4.4.302+] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: WDC Product: WD60EFRX-68L0BN1 Revision: 0A82 User Capacity: 6,001,175,126,016 bytes [6.00 TB] Logical block size: 512 bytes Physical block size: 4096 bytes LU is fully provisioned Rotation Rate: 5700 rpm Logical Unit id: 0x50014ee264a2191c Serial number: WD-WX31D87DYRFY Device type: disk Local Time is: Fri Oct 3 16:54:19 2025 CEST SMART support is: Unavailable - device lacks SMART capability. === START OF READ SMART DATA SECTION === Current Drive Temperature: 0 C Drive Trip Temperature: 0 C Error Counter logging not supported [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on'] Device does not support Self Test logging

C’est succinct …

Le support m’indique que le disque 1 est défectueux, en affichant ceci dans son mail : ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 146 001 051 Pre-fail Always In_the_past 1854 je ne sais pas d’où vient cette information; voici ce que j’obtiens de mon côté sur le gestionnaire de disques :

J’ai finalement pu envoyer un ordre de reboot via mon iPad donc la connexion DsFinder était encore active. après 1/2 heure, le système semble de nouveau parfaitement opérationnel, avec tous les paquets actifs. L’observateur d’événement n’a détecté aucune surcharge CPU ces derniers jours. Et je ne vois rien dans les log. je n’ai pas encore de news du support … À suivre …

Bonjour, Cette fois, même DS Finder ne me permet plus de voir mon NAS. En supposant que j’arrive à me connecter en SSH, quelqu’un peut t’il m’aider et me donner les commande à passer pour : - arrêter proprement Plex (directement le paquet plex) - arrêter proprement Docker. - redémarrer proprement le NaS merci !