Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Matériel

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 :

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.


continue reading...

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.

Niveau :      
Résumé : ionice

Vous avez maintenant pris l'habitude de lancer vos programmes gourmands avec nice pour éviter qu'ils ne monopolisent le processeur. C'est bien, mais il leur arrive encore parfois de consommer tout les accès dique et de faire ramer votre swap.

Et le sauveur s'appelle ionice. Son utilisation est simple :

$ ionice -c 2 -n 4 /usr/local/monscript

Mais que veulent dire -c 2 et -n 4 ? Il s'agit simplement de la classe et de la priorité.

  • -c 1 : temps réel, ne pas utiliser sous peine de geler la machine
  • -c 2 : standard on donne acces au disque dès qu'on en a l'occasion
  • -c 3 : on donne accès au disque lorsque personne ne l'a demand2 depuis un certain temps (quasiment jamais)

Le -n donne le niveau de priorité à l'intérieur d'une classe. Pour la classe 2 il y a 8 niveaux de 0 à 7 (0 étant la plus forte priorité). Tout comme celles de nice, ces priorités sont héritées.

Pour récupérer les informations pour un processus existant à partir de son pid :

$ ionice -p1

Vous constaterez que la plupart des processus sont dans la classe none. Selon les documentations cela connespond à -c2 -n4 ou à un calcul en fonction de la valeur de nice du preocessus.

Ainsi pour lancer un programme particulièrement gourmand je vous conseille quelque chose du genre

$ nice -n 19 ionice -c2 -n7 /usr/local/monscript

Passons à une partie plus technique. Ceci n'est possible que parce que le noyau contient un scheduler d'io. C'est une innovation récente. Ce n'est que depuis le 2.6.18 que le scheduler cfq est présent par défaut et c'est le seul qui supporte ces priorités. Mais ce n'est pas le seul à exister. Vous pouvez en compiler plusieurs et en changer soit au boot (avec l'option elevator=) soit après le boot disque par disque avec la commande

$ echo "cfq" > /sys/block/hda/queue/scheduler

Le choix d'un bon scheduler peut influencer les performances de vos serveurs de base de données ...

La documentation se trouve dans le répertoire Documentation/block des sources du noyau.