[Linux] statistiques disque SSD installation Linux Mint 18

[Christophe Courtois]

Hello,

Le 13/11/2016 à 22:12, Cyril Chaboisseau a écrit :
> * Christophe Courtois <christophe@::1> [2016-11-13 19:14 +0100]:
>>> il faudrait voir s'il n'existe pas un outil de métrologie (à la munin)
>>> permettant de grapher les écritures d'un disque SSD
>> un bête iotop ?
> non, j'ai bien dit métrologie
> pas du monitoring temps réel qui ne me donne qu'un instantané
> ce que j'aime avec munin, c'est que je peux avoir les infos...

Je connais, j'ai le même à la maison ;-)

iotop -a pour cumuler depuis le démarrage ?

>>> là c'est plus progressif et ça peut être contrecarré
>>> néanmoins, il faut _justement_ suivre les problèmes qui apparaissent sur
>>> l'usure des blocs
>> Ce n'est pas géré par l'électronique des disques (hard ou ssd) ?
> si, mais avec smartctl tu as un indicateur du nombre de secteurs
> réalloués (et donc défectueux)
> le problème c'est que certaines valeurs ne sont pas tout le temps très
> lisibles ni évidentes à dire si c'est un signe avant-coureur d'un disque
> qui va lâcher

Pas facile. J'ai des disques qui hurlent alors qu'ils fonctionnent
parfaitement (pour le moment, et bien sûr ils n'ont plus de données
critiques).

>>> de toutes façon, je me dit que si c'est utile, quelqu'un (souvent une
>>> boite) va se donner la peine de l'inclure
>>> et donc, si ça n'a pas été fait jusqu'à présent, c'est qu'il y a un loup
>> Parfois tu as des surprises. Ceux qui trouvent ça utiles n'ont pas les
>> compétences, celui qui connaît le truc n'a pas le temps ou l'envie de
>> finaliser, ça reste en bas des todo listes parce qu'il y a toujours autre
>> chose, etc.
> bof, 'faut voir mais j'ai quand même l'impression que si une société
> (éditeur ou constructeur informatique ou bien plus rarement la PMI/PME
> qui n'a rien à voir avec l'informatique) a un besoin particulier et se
> rends compte que ça peut lui être utile, alors elle s'arrangera pour
> intégrer le patch d'un façon à ce que ça soit facile à maintenir dans le
> temps
> (bon, là tu pourrais dire que je rêve mais je crois pouvoir te donner
> plusieurs exemples de financement de correctifs, intégration de patch
> dans le noyau et autres financement par des boites)

Oh, il y a palanquée.
Mais ça dépendra du milieu. Chez les libristes ou les entreprises à
dominante technophile  il peut y avoir volonté, voire compétence, et
l'obstination pour faire inclure une fonctionnalité alors que la mise en
place dans la prochaine version de Debian/PostgreSQL/whatever peut
prendre une année ou plus (même pour un patch d'une ligne quand il faut
recompiler et qu'il y a toute une chaîne). Certains projets sont
tatillons sur l'intégration (à raison, sur le long terme), bref ça prend
du temps et donc de l'argent, si même le patch finit dans la version
officielle.

D'autres milieux partiront sur une vision "je ne touche pas" ou "je ne
fais confiance qu'à l'éditeur", ou se demandent pourquoi ils iraient
développer ça [si fonctionnalité non triviale]  ou veulent tout tout de
suite et en fait comptent les croix dans un comparatif avec d'autres
produits. Ne parlons pas des endroits où "bosser sur quelque chose pour
le redistribuer gratuitement" génère une incompréhension (ils aiment
souvent aussi le "pas assez cher, mon fils !"). Évidemment les libristes
éventuels ne travaillent pour la communauté qu'en sous-marin, aucune
fonctionnalité majeure (développement en mois.hommes) ne sortira de ces
endroits. Les grandes SSII sont coupables, elles ont plein de
ressources, voient les besoins, ne contribuent jamais spontanément à ma
connaissance, alors que le modèle libre+services+indépendance des
éditeurs serait leur intérêt.

Cas intermédiaire : les volontaires bien intentionnés qui patchent,
voire recompilent eux-mêmes, pour un détail ou une norme interne
quelconque, sans se rendre compte du poids en administration d'une
installation hors des binaires de la communauté : non, on ne recompile
pas soi-même PostgreSQL/MariaDB/Postfix/Linux sur un serveur de prod
pour le plaisir de changer les chemins par défaut ou une illusoire
optimisation de la taille de bloc. Ou alors c'est du dév, pas de la
prod. Ou bien ça touche au coeur de métier et il y a un max de ressources.

> d'ailleurs, Debian bénéficie (modestement) de ce type de sponsoring
> ainsi que PostgreSQL (il en existe probablement une palanquée d'autres)

Pour ce dernier, j'en sais quelque chose :-)


-- 
Christophe