[Toulibre] Surveiller l'état des disques durs

Mer 17 Juin 01:36:01 CEST 2015

On 15/06/2015 22:15, Jérôme wrote:
> Le Mon, 15 Jun 2015 19:30:58 +0200,
> Aymeric <mulx at aplu.fr> a écrit :
>
>> Il faut aussi s'avoir lire les états S.M.A.R.T....
> Oui, rien que ça, c'est pas trivial... Je suis bien content que tu te
> proposes de regarder le mien.
>
>> Tu peux poster le logs que tu as avec ?
>> smartctl -a /dev/sda
>> (si sda est bien ton disque douteux).
> Le voici en PJ.
>
> Ces deux lignes sont les résultats des tests d'hier, donc depuis
> l'incident :
>
> # 1  Extended offline    Completed without error 00% 10273 - 
> # 2  Short offline       Completed without error 00% 10270 -

Ok, déjà ça signifie que tu as fais un test de surface (c'est ce que
fait l'extended ; c'est détaillé dans la partie offline data collection
capabilites = 0x5b).
Donc pas d'erreur de surface détecté c'est plutôt rassurant.
Sur la lecture des attributs (Vendor Specific SMART Attributes with
Thresholds) avec une comparaison des spec constructeur (1) et des
données habituels des disques durs :

Globabelement : tout est dans les normes (value || worst) > threshold

Quelques détail avec les valeurs « raw » :

12) Nombre de « Load cycle Count » tu es à 2323 sur 300000
constructeurs, valeur très faible donc aucun risque à ce niveau là. Ça
correspond d'ailleurs au nombre d’allumage, j'en conclu donc que soit tu
fais des accès disques en permanence lorsque le disque est allumé, soit
Linux n'effectue jamais de « park head » (c'est souvent le cas sur les
PC fixe, sur les PC portable en général il y a un paquet pour reposer
les têtes).

9) PoH 10000 heures, statistiquement les disques ont une durée de vie de
50000 heures, pas d'inquiétude non plus.

5, 196, 197) RSC ; 6 secteurs ré-alloué, c'est « trop » pour un disque
ça signifie un problème de surface, idéalement c'est 0.. mais ce n'est
pas critique tant que cette valeur n'augmente plus ou très lentement (il
peut avoir des secteurs défectueux sur disque neuf, malgré le test
d'init effectué par le constructeur lors de la programmation de la
smart... même si ça ne devrait pas)
-> S’agissant d'un disque Hitachi je ne suis pas vraiment surpris :-D
(je commence à me demander si Hitachi fait vraiment une programmation de
la smart en fonction du disque et pas plutôt par lot.. voir pas du tout)
-> Ce n'est pas spécifié dans la doc mais tu dois avoir environ
2000/3000 secteurs de réserve. Ce que tu peux faire c'est faire une
réecriture complète sur le disque et vérifier que cette valeur n'a pas
changé.
    Si cette valeur ou la valeur de 197 augmente ça signifie que :
         1) Le test extented est foireux ... (bug du firmware?)
         2) La surface est défectueuse  ou qu'il n'y a jamais eu d'init
de la smart
197) pas de secteur en attente de ré-allocation c'est bon aussi.

7 & 10) Pas d'erreur de mécanique placement des têtes ou rotation :)

En résumé :
=> Surveiller l'évolution de 5, 196 et 197. si c'est valeurs augmentent
il faut changer le disque, ce n'est pas la peine d'attendre, si ça reste
stable sur plusieurs semaines/mois pas d'inquiétude.

D'après la partie log je dirais que tu as des erreurs de secteurs
défectueux à 589h de fonctionnement, rien depuis.
Possiblement c'est lorsque le disque était dans un des extrêmes en
température (14° ou 39°C)

[1]:
http://www.hgst.com/tech/techlib.nsf/techdocs/D70FC3A0F32161868625747B00832876/$file/Deskstar_7K1000.B_DS.pdf

>
>> Tu as peut être des secteurs défectueux en pending, si il y a de la
>> place en réserve il faut récrire dessus pour que S.M.A.R.T. fasse la
>> ré-allocation (et si il y a des secteurs défectueux, selon historique
>> du disque, je te recommande de faire un effacement complet destructif)
> Hmmm.... ? Je sais pas. Tu le vois dans mon log ?
Cf au dessus (5,196,197).
>> Le RAID par mdadm (je ne connais pas les capacités RAID de lvm)
>> execute un check régulièrement (en tout cas sur debian).
>> Le test est lancé par crontab une fois par mois via (source
>> /etc/cron.d/mdadm)
>> /usr/share/mdadm/checkarray --all
>> Le comportement de MDADM si est disque n'est pas conforme c'est de le
>> retirer du groupe, ce qui génère une alerte visible dans /proc/mdadm
>> ou via mdadm. Comme dit ailleurs tu peux catcher ces alertes pour
>> recevoir un mail.
>>
>> Du RAID avec btrfs il faut exécuter un scrub régulièrement, je ne sais
>> pas si c'est passer dans cron ou pas.
>>
>> Les autres FS qui font du RAID (ZFS), je ne sais pas.
> Par défaut, je pense utiliser du ext4. Et debian.
>
>>> -> Est-il possible de dialoguer avec un RAID logiciel pour avoir des
>>> alertes liées à la couche RAID, autres que celles de smartmontools
>>> qui sont au niveau disque ?
>> Si tu as RAID logiciel tu peux toujours interroger tes disques dur
>> directement par smartctl.
> Oui, et sur le serveur du boulot, j'y arrive aussi grâce à la bonne
> option. Mais justement, ma question portait sur la possibilité d'avoir
> un statut du RAID, pas de chaque disque. En raid logiciel, mdadm écrit
> dans /proc/mdadm, tu viens de l'écrire, donc là c'est bon. Mais sur le
> serveur du boulot, je ne sais pas parler au contrôleur de RAID matériel.
> Mais peut-être que c'est pas intéressant. Si la seule chose que le RAID
> est capable de dire c'est qu'il a enlevé un disque qui marchait plus,
> SMART doit pouvoir le remonter aussi s'il n'a plus accès au disque.

Selon les cartes, tu as un truc via smart, sinon c'est outil constructeur...
Ne pas oublier lorsqu'on fait du RAID, deux disques du mêmes fabriquant,
même modèle, même série ont une forte probabilité de tomber en panne en
même temps... (ou suffisamment proche pour ne pas laisser le temps à
raid de se réparer...)

> Sur ma liste de bonnes intentions, il y a la mise en place du RAID, et
> j'aimerais bien aussi mettre en place des sauvegardes croisées avec un
> copain qui habite très loin. Ainsi, si une météorite explose tout le
> sud-ouest, j'aurai pas tout perdu.

Enfin.. si une météorite explose tout le sud-ouest, je ne suis pas sûr
que tes backups soit le premier de tes soucis. ^^
> Au passage, j'ai acheté l'ordi d'occasion, c'est un Dell XPS 630 et le
> disque c'est un Hitachi Deskstar.

> La machine a un contrôleur RAID matériel mais je préfère faire du RAID
> logiciel au cas où la carte mère rende l'âme. Il manquerait plus que
> ça.
Le RAID HW c'est bien.. quand c'est une vrai carte pro (avec batterie de
backup intégré.. etc), pas les fake-hw-raid des cartes mères de pc
standard qui monopolise le southbridge pour faire le raid ce qui fait
qu'on n'a pas de meilleure perf qu'avec du soft raid...
Des quelques tests que j'ai eu l'occasion de faire, il semble que le
fake-hw-raid fait du JBOD pour le raid0 est du Intel Matrix RAID en
guise de RAID1, ce que mdadm arrive à relire ...
> J'hésitais entre 2 disques en RAID 1 et trois en RAID 5 (doubler le
> volume pour +50% de coût seulement) mais à la réflexion, c'est
> peut-être aussi bien RAID 1 pour moi car s'il arrive quoi que ce soit
> au système, je peux toujours lire chaque disque indépendamment.

2 disques en RAID1 tu auras de meilleures perf (max = vitesse max en
parallèle du south-bridge), le RAID5 est consommateur de CPU et d'I/O...
>
> C'est une question annexe, mais tant que j'y suis, je veux bien
> confirmation qu'en RAID 1, je peux démonter un disque et le lire
> ailleurs et je peux utiliser un live-cd pour lire son contenu, alors
> qu'en RAID 5, j'ai besoin d'avoir le système lancé avec mdadm et le
> RAID complet (en tout cas deux disques) pour que ça marche. Et si je
> démonte deux disques, j'ai pas un accès trivial à la donnée. Si j'ai
> bien compris, alors autant partir sur du RAID 1. Le mieux est l'ennemi
> du bien.

Soft raid linux :
-> metadata 0.9 ou 1.0 tu peux relire sans mdadm
-> metadata 1.1 ou 1.2 il faut mdadm pour relire le raid.
Après si c'est raid1 tu peux toujours activer l'array en degraded avec
un seul disque sur les deux..

A+

Aymeric

-- 
Aymeric