Nous avons un serveur Linux qui est très utilisé depuis 3 ans. Nous y exécutons un certain nombre de serveurs virtualisés, certains qui ne se sont pas bien comportés, et pendant un temps considérable, la capacité io du serveur a été dépassée, ce qui a entraîné de mauvais iowait. Il dispose de 4 disques SATA Barracuda de 500 Go connectés à un contrôleur RAID 3com. 1 Drive a le système d'exploitation et les 3 autres sont configurés raid-5.
Nous avons maintenant un débat sur l'état des disques et sur leur défaillance active.
Voici une partie de la sortie pour 1 des 4 disques. Ils ont tous des statistiques relativement similaires:
Numéro de révision de la structure de données des attributs SMART: 10 Attributs SMART spécifiques au fournisseur avec seuils: ID # ATTRIBUTE_NAME DRAPEAU VALEUR PIRE TYPE DE SEUIL MIS À JOUR LORSQUE_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pré-échec toujours - 169074425 3 Spin_Up_Time 0x0003 095 092 000 Pré-échec toujours - 0 4 Start_Stop_Count 0x0032 100100 020 Old_age Always - 26 5 Reallocated_Sector_Ct 0x0033 100100 036 Pré-échec toujours - 0 7 Seek_Error_Rate 0x000f 077 060 030 Pré-échec toujours - 200009354607 9 Power_On_Hours 0x0032 069 069 000 Old_age Always - 27856 10 Spin_Retry_Count 0x0013 100 100 097 Pré-échec toujours - 1 12 Power_Cycle_Count 0x0032 100100 020 Old_age Always - 26 184 Unknown_Attribute 0x0032 100100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100100 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 100100 000 Old_age Always - 1 189 High_Fly_Writes 0x003a 100100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age Always - 29 (Lifetime Min / Max 26/37) 194 Temperature_Celsius 0x0022 029 040 000 Old_age Always - 29 (0 21 0 0) 195 Hardware_ECC_Recovered 0x001a 046033000 Old_age Always - 169074425 197 Current_Pending_Sector 0x0012 100100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 Version du journal des erreurs SMART: 1 Aucune erreur enregistrée
Mon interprétation de ceci est que nous n'avons pas eu de mauvais secteurs ou d'autres indications que l'un des disques tombe en panne.
Cependant, les valeurs Raw_Read_Error_Rate et Seek_Error_Rate élevées sont signalées comme des indications que les lecteurs sont en train de mourir.
Réponses:
D'après mon expérience, les Seagates ont des nombres étranges pour ces deux attributs SMART. Lors du diagnostic d'un Seagate, j'ai tendance à les ignorer et à regarder de plus près d'autres domaines tels que le nombre de secteurs réaffectés. Bien sûr, en cas de doute, remplacez le lecteur, mais même les tout nouveaux Seagates auront des chiffres élevés pour ces attributs.
la source
Pour les disques Seagate (et peut-être aussi certains anciens de WD), Seek_Error_Rate et Raw_Read_Error_Rate sont des nombres de 48 bits, où les 16 bits les plus significatifs sont un nombre d'erreurs et les 32 bits les plus faibles représentent un certain nombre d'opérations.
Votre disque a donc effectué 2440858991 recherches, dont 46 ont échoué. D'après mon expérience avec les disques Seagate, ils ont tendance à échouer lorsque le nombre d'erreurs dépasse 1000. YMMV.
la source
Le "taux d'erreur de recherche" et le "taux d'erreur de lecture brute" RAW_VALUES n'ont pratiquement aucun sens pour quiconque, sauf le support de Seagate. Comme d'autres l'ont souligné, les valeurs brutes de paramètres tels que "le nombre de secteurs réalloués" ou les entrées dans le journal des erreurs du lecteur sont plus susceptibles d'indiquer une probabilité plus élevée de panne.
Mais vous pouvez jeter un œil aux données interprétées dans les colonnes VALUE, WORST et THRESH qui sont censées être lues comme des jauges:
Cela signifie que votre taux d'erreur de recherche est actuellement considéré comme "77% bon" et est signalé comme un problème par SMART lorsqu'il atteint "30% bon". Il avait été aussi bas que "60% bon" une fois, mais s'est magiquement rétabli depuis. Notez que les valeurs interprétées sont calculées par la logique SMART du lecteur en interne et le calcul exact peut ou non être publié par le fabricant et ne peut généralement pas être modifié par l'utilisateur.
Personnellement, je considère un lecteur contenant des entrées de journal d'erreurs comme "défaillant" et j'exhorte à un remplacement dès qu'elles se produisent. Mais dans l'ensemble, les données SMART se sont révélées être un indicateur plutôt faible de la prédiction des défaillances, comme l'a révélé un document de recherche publié par Google .
la source
J'ai réalisé que cette discussion est un peu ancienne mais je veux ajouter mes 2 cents. J'ai trouvé que l'information intelligente est un assez bon indicateur de pré-échec. Lorsque vous obtenez un seuil intelligent déclenché, remplacez le lecteur. C'est à cela que servent ces seuils.
La grande majorité du temps, vous commencerez à voir de mauvais secteurs. C'est un signe certain que le lecteur commence à échouer. SMART m'a sauvé plusieurs fois. J'utilise le logiciel RAID 1 et c'est très utile car vous remplacez simplement le disque défectueux et reconstruisez la matrice.
Je fais également des auto-tests courts et longs chaque semaine.
Ou ajoutez-le /etc/smartd.conf et faites-le vous envoyer un e-mail s'il y a des erreurs
Assurez-vous d'installer logwatch et de rediriger root vers une adresse e-mail et vérifiez les e-mails quotidiens de logwatch. Les drapeaux déclenchés SMARTD apparaîtront là-bas, mais cela ne sert à rien si personne ne surveille cela régulièrement.
la source
Oui, ces champs semblent mauvais mais je ne fais plus confiance aux informations rapportées par smart (ma machine de test a un lecteur qui devrait être mort il y a longtemps si vous lisez les données avec smartctrl) Le fait est que vous avez signalé haute iowait et les lecteurs ont 3 ans. Cela devrait vous suffire pour changer les disques.
la source
Désolé de commettre de la nécromancie sur ce post, mais d'après mon expérience, les champs "Raw Read Error Rate" et "Hardware ECC Recovered" pour un disque Seagate iront littéralement partout et augmenteront constamment dans la plage de milliards de milliards à quel point ils 'reviendrai à zéro pour continuer le processus à nouveau. J'ai un Seagate ST9750420AS qui a eu ce problème depuis le premier jour et fonctionne toujours très bien même après quelques années et plus de 3500 heures d'utilisation.
Je pense que ces champs peuvent être ignorés en toute sécurité si vous en exécutez un dans votre cas. Assurez-vous simplement que les deux champs signalent le même nombre et sont constamment synchronisés. S'ils ne le sont pas ... eh bien ... cela pourrait en fait signifier un problème.
la source
Pour automatiser les calculs de cette réponse , utilisez le calculateur javascript en ligne:
https://yksi.ml/
Cela vous dira:
La calculatrice est valable pour Seagate:
Pour plus d'informations sur le calcul de la normalisation (entre 0 et 100 valeurs), voir cet article .
la source