Linux Attitude

Niveau :
Résumé : sensors-detect ; sensors; hddtemp; fancontrol

Sensors

Comment connaître les différentes températures à l'intérieur de votre machine ? Il y a des capteurs, donc il y a bien une information quelque part. Linux a tous les drivers nécessaires, mais pour ceux qui se sont essayé à regarder, c'est difficile de savoir qui sert à quoi. Heureusement, il y a lm-sensors pour venir à notre secours.

Pour avoir la liste de tous les capteurs disponibles sur la machine ainsi que les driver linux associés à charger, il existe une commande toute simple une fois le paquet lm-sensors installé :

$ sensors-detect

Cette commande scanne le matériel, vous pose une question ou deux et termine en vous listant les modules noyau à charger pour pouvoir obtenir les valeurs. Deux choses à faire :

# On charge le(s) module(s)
$ modprobe lemodule
# Et on automatise ça pour le prochain reboot
$ echo lemodule >> /etc/modules

Et voilà, il ne vous reste plus qu'à lire les valeurs. Pour cela, vous avez plusieurs outils :

# lecture simple des valeurs en mode texte
$ sensors 
# lecture avec interface graphique (ne marche pas chez moi)
$ xsensors

Ou les traditionnelles applet qu'on peut trouver sur gnome, kde, gkrellm, windowmaker ...

Hddtemp

Si vous voulez aussi lire la température de vos disque, il existe hddtemp du paquet éponyme. Celui-ci marche directement en ligne de commande :

# Il faut être root
$ hddtemp /dev/sda

Il existe aussi en mode démon, une fois installé, modifiez /etc/default/hddtemp (debian) et relancez le démon :

$ /etc/init.d/hddtemp restart
# vérifions qu'il marche
$ telnet localhost 7634

Et voila, il ne vous reste plus qu'a ajouter le disque dur dans l'applet.

Attention, l'applet de gnome nécessite d'être redémarrée pour détecter hddtemp.

Fancontrol

C'est la fête, passons maintenant aux ventilateurs. Vous avez déjà remarqué que vous pouvez avoir la vitesse de rotation dans vos applet. Ajoutez la au moins temporairement, ça peut vous être utile pour la suite.

En effet, nous n'allons pas seulement lire la vitesse des ventilateurs, mais nous allons la modifier. Pour ceux qui veulent regarder sous le capot, tout cela se trouve dans /sys/devices/platform/<sensordriver>/

Fancontrol est un paquet qui contient deux choses : un script permettant de régler automatiquement la vitesse de rotation des ventilateurs et un outil permettant de le configurer sans se forcer.

Pour utiliser fancontrol, il faut avoir des sensors opérationnels. Gardez de préférence un oeil sur votre applet pour éviter les débordements de température et pour savoir quoi répondre au script.

$ pwmconfig

Ce script vous pose plein de questions, arrête les ventilateurs, les relance, les ralentit ... dans le but de savoir quel ventilateur fait quoi, à quel capteur de température on peut l'associer et comment il marche. Sachez au passage que les processeurs acceptent des températures assez élevées, pas besoin de les forcer à 40°C, vous économiserez du bruit. Regardez la doc de votre fabricant si vous voulez un avis sérieux.

Le script pose 2 questions difficiles à comprendre

• MINSTART est la valeur de configuration au dessus de laquelle le ventilateur commence à tourner
• MINSTOP est la valeur de configuration au dessous de laquelle le ventilateur s'arrête de tourner

De façon générale, MINSTOP doit être supérieur à MINSTART (hystérésis), mais les valeurs sont assez proches. Vous pouvez aussi choisir ces valeurs par rapport à ce que vous entendez plutôt qu'à la vitesse réelle de rotation.

Une fois le tout configuré :

$ /etc/init.d/fancontrol start

Et écoutez ce silence en provenance de votre ventilateur. Surtout lorsque vous faites des activités peu intensives.

Niveau :
Résumé : pv ; vg ; lv

LVM : Logical Volume Management. C'est un système qui permet de mixer une ou plusieurs partitions pour en faire un ou plusieurs périphériques de blocs. À quoi cela peut-il bien servir ? C'est tout d'abord une question de flexibilité. Imaginez pouvoir agrandir ou réduire une partition facilement, parfois même sans démonter le système de fichier. Imaginez pouvoir agrandir une partition de façon à ce qu'elle tienne sur 2 disques. LVM apporte aussi d'autres fonctionnalités que nous verrons un peu plus tard.

Un dessin valant mieux qu'un long article, voici le principe de fonctionnement de LVM :

Donc à la première ligne vous prenez des partitions que vous transformez en pv (physical volume) :

$ pvcreate /dev/sda2
$ pvcreate /dev/sda4
$ pvcreate /dev/sdb1
# on verifie qu'ils sont reconnus
$ pvdisplay

Ensuite vous les regroupez dans un vg (volume group) :

# note : permettez-vous de choisir un nom plus explicite que vg0
$ vgcreate vg0 /dev/sda2 /dev/sda4 /dev/sdb1
# on vérifie qu'il est reconnu
$ vgdisplay

Et enfin vous redécoupez celui-ci en différents lv (logical volume) :

# note : permettez-vous de choisir un nom plus explicite que lv0
$ lvcreate -L 10G -n lv0 vg0
$ lvcreate -l 100%FREE -n lv1 vg0
# on vérifie qu'ils sont reconnus
$ lvdisplay

Notez au passage qu'il y a de nombreux moyens de spécifier la taille du volume (en taille absolue ou en pourcentage du total ou de l'espace libre).

Voila, on peut maintenant utiliser nos lv comme des partitions normales :

$ mke2fs -j /dev/vg0/lv0
$ mount /dev/vg0/lv0 /mnt

Enfin, il faut tout de même faire attention si on veut l'utiliser pour la partition /. En effet, le noyau ne scanne pas de lui-même les partitions lvm, ce sont les utilitaires pvscan, vgscan et vgchange qui doivent être appelés pour les activer. Ils le sont automatiquement par votre distribution, mais il faut disposer d'un / pour les avoir. Donc si vous voulez une racine en lvm, il vous faudra nécessairement un initrd (c'est le cas par défaut pour la plupart des distributions).

D'autre part pour une bonne détection au démarrage, fixez le type de vos partitions à "Linux LVM", (0x8E). Par exemple avec cfdisk.

$ cfdisk /dev/sda

Dans un prochain article nous verrons les fonctionnalités excitantes : redimensionement , snapshot, raid 0, raid 1 ...

En attendant, la référence se trouve sur le LVM howto

Niveau :
Résumé : little endian, big endian

On nous parle souvent de problèmes de petits indiens et de grands indiens, hé bien c'est du flan, les indiens n'existent pas. Si on fait exception des mal comprenant, la traduction correcte est petit boutiens, et gros boutiens. L'information nous vient de Gulliver lorsqu'il est revenu de Lilliput. Il y a rencontré un peuple divisé en deux, les premiers prétendaient qu'un oeuf devait se tenir par le petit bout alors que les autres affirmaient le contraire (à moins que ce ne soit l'opposé).

Dans l'informatique, les guerres de religions sont du même style. Par exemple, comment écririez vous cent vingt trois ? Les gros boutiens (ou bien est-ce gros boutistes ?), diraient 123 alors que les petits boutiens diraient 321.

Les premiers affirment que c'est plus logique d'avoir d'abord l'ordre de grandeur, et ensuite l'information de précision. Les seconds disent qu'il est plus intéressant de pouvoir lire les nombres d'une longueur théoriquement indéfinie, puisqu'on peut ajouter des chiffres aussi longtemps qu'on lit. En fait la différence est essentiellement affaire de religion puisque les processeurs lisent toujours des entiers de taille fixe, bien qu'il puisse y avoir un léger avantage au développement d'un processeur compatible lisant des entiers plus gros (64 bits) sur une architecture little endian.

Mais qui fait partie de quelle église (quel endianness) ?

• x68 : little endian
• sparc : big endian
• powerPC : big endian
• ARM : agnostique, supporte les 2
• PDP-11 : bi, little et big endian simultanément selon les octets considérés
• IP : big endian

Hé oui, internet et quasiment tous les réseaux ont un ordre qui est le plus gros d'abord. C'est pourquoi les fonctions ntoh* et hton* ont été définies (network to hardware et inversement).

Voila, maintenant vous savez pourquoi vous ne pouvez pas simplement transporter votre base de données (ou votre tar) de votre pentium vers votre station sparc sans avoir de problèmes ...

Niveau :
Résumé : gnu ddrescue

Souvenez-vous, au premier épisode vous récupériez un disque abîmé avec dd, la technique et la répétition aidant, vous étiez passé à dd_rescue; aidé par votre (malheureusement trop) occasionnel compagnon par2.

Depuis cette époque, les gens on grandi et un petit nouveau est né. À mon avis, son auteur a fait un erreur stratégique en lui donnant presque le nom de son parrain. Il s'appelle gnu ddrescue, et seul un '_' et un gnu les séparent. Pourtant le petit nouveau a été écrit sans référence à dd_rescue.

Trêve de bavardage, récupérons ... je me coupe la parole à moi-même pour indiquer que debian met le binaire dans /sbin, mais pourquoi là ? Il n'y a pas que les admins qui ont le droit de perdre des données ! Donc, récupérons disais-je :

$ /sbin/ddrescue /dev/cdrom ~/recup.iso

Mais pourquoi utiliser celui-ci plutôt que l'autre ? Tout d'abord parce qu'il été réécrit en C et est bien plus rapide (pas de lancement de sous processus, et certaines opérations sont simplifiées). Ensuite parce que son algorithme est un peu plus intéressant. En effet, contrairement à dd_rescue, il ne cherche pas à réparer et à obtenir tout dès le début. Il fonctionne par parcours successifs du fichier à récupérer, tout d'abord avec des grosses mailles, puis de plus en plus fin. Ce qui veut dire qu'en pourcentage, vous récupérer le maximum de donnes au début, puis progressivement des parties de plus en plus détruites.

D'autre part, ddrescue peut être lancé plusieurs fois et il récupérera de nouvelles données à chaque fois. Ce qui veut dire qu'on peut prendre son temps pour la récupération (il résiste aux crash), mais aussi qu'on peut faire de la récupération à partir de plusieurs copies abîmées.

Donc pour un usage un peu plus évolué, on aura simplement besoin d'un fichier de log

# on peut lancer cette commande autant de fois qu'on veut
$ /sbin/ddrescue /dev/cdrom ~/recup.iso ~/logfile

Vous trouverez dans le man, quelques options spécifiques à certains problèmes comme -s pour limiter la taille de fichier ou -i pour commencer au milieu d'un disque.

Enfin, n'oubliez pas, dans le cas d'une récupération d'un système de fichier, il vaut mieux laisser fsck bidouiller sur une copie pour pouvoir recommencer avec d'autres outils.

Niveau :
Résumé : smartctl

La dernière fois, nous avons trouvé un outil tout fait pour surveiller nos disques. C'est bien, mais nous allons maintenant nous plonger un peu plus dans SMART.

Lecture des infos

Il est possible de gérer à la main les commandes smart. Le but étant d'avoir les détails de ce qui va ou ne va pas. La commande de base est smartctl. Pour tout savoir sur les données smart :

$ smartctl -a /dev/hda

Tout d'abord parlons des attributs (le plus intéressant) :

$ smartctl -A /dev/hda
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   051   046   006    Pre-fail  Always       -       230474091
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   020    Old_age   Always       -       1105
...
194 Temperature_Celsius     0x0022   049   060   000    Old_age   Always       -       49

Maintenant il faut savoir lire ces valeurs. Le type Old_age indique qu'un erreur n'est pas grave, c'est seulement un indicateur de vieillesse. Au contraire Pre-fail indique que le disque risque de vous causer des soucis très bientôt. Updated indique si la valeur est mise à jour fréquemment (Always) du simple fait que smart soit activé sur le disque, ou seulement lorsque des tests sont lancés (Offline). En effet, smart doit être activé sur votre disque si vous voulez avoir des valeurs correctes. S'il ne l'est pas :

$ smartctl -s on /dev/hda
# pour savoir si smart est activé
$ smartctl -i /dev/hda

Enfin les 3 valeurs "value", "worst" et "thresh" indiquent l'état du disque. Value est la valeur actuelle (sans unité et sans interprétation), worst est la valeur enregistrée la plus proche de l'erreur, et enfin thresh indique un seuil au dessous duquel valeur ne devrait jamais descendre (sinon alerte). Raw_value vous donnera l'interprétation de value si vous connaissez les unités (doc constructeur toussa).

La liste des attributs possible est bien décrite par wikipedia.

Les tests

En plus des données collectées en continu par smart, il est possible de lancer des tests plus longs. Il existe 4 types de test :

• offline : test court mettant à jour les attributs "offline".
• short et long selftest : test court ou long sur les performances, les problèmes électriques et les lectures physiques.
• conveyance (disponible uniquement sur certains disques ATA) : test sur d'éventuels problèmes liés au transport du disque.
• select (disponible uniquement sur certains disques ATA) : semblable à un test long mais sur une seule partie du disque

Les tests offline peuvent être faits automatiquement par le disque toutes les 4 heures grâce à la commande suivante :

$ smartctl -o on /dev/hda

Contrairement à ce qui est dit dans la documentation, il faut s'attendre à quelques ralentissements des accès disques pendant un test (surtout pendant un test long). Pour lancer un test manuellement, on demande à smartctl :

$ smartctl -t long /dev/hda

La durée estimée du test est alors indiquée. Selon les disques le fait qu'un test est en cours se voit soit dans les capabilities, soit dans les logs :

# lecture des capabilities
$ smartctl -c /dev/hda
# lecture des logs de test
$ smartctl -l selftest /dev/hda

Une fois le test terminé, les éventuelles erreurs apparaissent dans les logs (et les valeurs offline des attributs sont mis à jour) :

$ smartctl -l selftest /dev/hda
$ smartctl -l error /dev/hda
$ smartctl -A /dev/hda

Si comme moi vous avez des informations comme celles-ci :

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
195 Hardware_ECC_Recovered  0x001a   051   046   000    Old_age   Always       -       75004710
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     18071         24102132
# 2  Extended offline    Completed: read failure       90%     18070         24099461

C'est que vous avez déjà perdu quelques octets. Tout n'est pas perdu, puisque le disque est capable de réallouer dynamiquement la position de ses secteurs pour allonger sa propre durée de vie. Disons que votre disque est sur la mauvaise pente et que c'est à vous de décider ce qu'il faut en faire.

Notez donc ces erreurs sur certains secteurs du disque. Le texte suivant vous expliquera comment retrouver quel fichier est affecté, voire comment forcer le disque à réallouer ce secteur.

Niveau :
Résumé : smartmontool ; smartd

Les disques ont une durée de vie très courte, pendant 5 ans j'ai eu une moyenne d'un disque grillé par an ! Google a quelques statistiques très intéressantes à ce sujet Ici et en résumé ici

Maintenant le rythme s'est un peu calmé, mais je redoute le prochain crash. Les solutions sont assez simple : tout d'abord faire un raid ET le monitorer. Mais si vous n'avez as les moyens ou si vous vous voulez faire encore mieux, vous pouvez surveiller directement vos disques. En effet, il existe un standard implémenté sur tous les disques nommés smart.

Pour surveiller vos disques c'est simple

# adaptez à votre distribution ;-)
$ apt-get install smartmontools

Vous aurez alors un démon qui surveillera l'état de vos disques et vous préviendra lorsqu'un seuil est atteint (température, nombre d'erreurs ...). Par défaut il scanne vos disques au démarrage pour savoir lesquels monitorer. Si cela vous ennuie, vous pouvez le spécifier un par un dans le fichier de configuration /etc/smartd.conf, la man de smartd et smartd.conf vous renseignera mieux que moi que sur son format. Ensuite si un problème survient, il vous enverra un mail, généralement à root comme indiqué dans la configuration.

Et le Diagnostic ?

Vous aurez droit aux alertes de température, en général ce n'est pas grave (les statistiques nous disent que les disques supportent bien plus que ce que disent les constructeurs). Vous aurez aussi les alertes disant que votre disque a eu des erreurs de lecture (ecc ou correctible error) qui sont en pratiques corrigées toutes seules, elles indiquent seulement que votre disque vieillit.

Ensuite, un peu plus grave plus grave, lorsque vous tomberez sur des erreurs non corrigées. Bien qu'en général cela n'impacte pas vraiment le fonctionnement de votre machine (perte de votre tête sur vos photos de vacances), cela veut dire que vous allez prochainement avoir des problèmes. Bien sûr prochainement ne veut rien dire, j'ai vu des disques tenir dans cet état plus d'un an. Si vous êtes sur un service ultra critique, rachetez, voire changez le disque dans votre raid. Si vous êtes chez vous, il est peut-être temps de penser au raid (même temporaire, le temps que le disque grille).

Enfin, l'état le plus grave (juste avant celui des logs noyau qui indique qu'il a des problème sur le bus), c'est lorsque SMART vous indique que le disque va griller dans les 24h (il prévient c'est déjà bien). Cette prédiction est assez réaliste. J'ai déjà vu ce cas deux fois et effectivement, le lendemain la machine ne pouvait plus booter. Vous savez ce qu'il vous reste à faire !

PS : Et si c'est trop tard, lisez un autre article qui vous expliquera comment à partir de secteurs abîmés on peut retrouver le fichier affecté voire comment forcer la réallocation des secteurs.

Niveau :
Résumé : alsa ; oss

On me demandait récemment quelle interface choisir pour le son des applications sous linux. Du point de vue du noyau vous avez le choix entre alsa et oss, qui sont deux séries de driver. Et du point de vue des application vous avez encore d'autres choix.

OSS (Open Sound System) est un système de driver son développé pour linux il y a quelque temps. Son auteur principal a comblé un manque car il n'en avait jamais existé avant. Mais son objectif était de vendre des drivers propriétaires et le développement des versions libres s'en est ressenti.

Après quelque temps des développeurs ont décidé d'écrire une nouvelle api pour le développement de driver son : alsa (Advanced Linux Sound Architecture). Du coup le noyau propose les deux dans sa configuration.

Le problème est que la plupart des applications ont été développées pour supporter oss. Heureusement, alsa fournit une couche de compatibilité oss et donc supporte les anciens logiciels. Alsa fournit aussi une nouvelle api permettant de mieux exploiter certaines cartes.

Maintenant du point de vue des api, les clients peuvent vous proposer d'utiliser esd, arts ou jack. Ce sont tous des démons qui essaient de fournir une api générique que tout le monde peut utiliser, et ils cachent derrière l'api qu'ils utilisent. En général ils se basent sur alsa, mais peuvent aussi utiliser oss voire parfois un autre démon (pratique pour faire tourner des applications conçues pour un seul démon). Un démon peut être bien utile si votre carte ne supporte pas plusieurs canaux, il le fera à votre place.

esd (Enlightenment Sound Daemon) est le démon privilégié des applications gnome.

arts est le démon privilégié des application kde (ce qui changera pour kde 4).

jack est un démon dédié à la faible latence et à l'utilisation à travers le réseau.

PS : on m'indique que j'oublie Pulse Audio qui cherche à être le remplaçant de esd.