Aujourd'hui les disques atteignent des limites qui n'avaient pas été prévues lorsqu'on les fabriquait comme des machines à laver (notez que le premier disque tournait déjà à 3600 tours par minute.

Les disques ont d'abord été adressés au format cylindre, tête, secteur (CHS), puis au format LBA. Les différentes limites ont évolué en fonctions de la taille du bus d'adressage.

Limites

Aujourd'hui on rencontre encore plusieurs limites. Tout d'abord au niveau logiciel, les partitions qui prévoyaient un adressage linéaire sur 32 bits des secteurs trouvent une limite à 2To (2^32 * 512).

Aujourd'hui au niveau du disque lui-même, les fabricants qui stockaient les informations de redondance et de structure du disque sur chaque secteur commencent à trouver cet espace très restreint.

Aujourd'hui les disques sont tellement gros que la lecture d'un disque entier est extrêmement longue, une erreur dans un fichier et la récupération du système de fichier devient une opération très lourde.

Aujourd'hui les disques sont tellement gros que la restauration d'un disque dans un raid prends un temps énorme, au point qu'il est possible d'avoir une seconde défaillance pendant ce temps.

Aujourd'hui les disques normaux sont tellement gros qu'on utilise le même disque pour plusieurs machines.

Aujourd'hui les disques sont tellement petits qu'on en utilise plusieurs par machine.

Avec tous ces problèmes, on voit beaucoup de choses évoluer.

RAID 6+1

Les disques étant de plus en plus lents et de plus en plus gros, on est déjà passé du raid5 au raid6 pour éviter les problèmes de lenteur lorsqu'un disque manquait, on envisage d'ajouter un nouveau disque de redondance pour éviter le cas où un 2e disque grille pendant la restauration du premier.

SAN

Maintenant tout le monde a un NAS chez lui, mais les serveurs utilisent des SANs qui se partagent sur des interfaces réseau standard et plus seulement SCSI ou Fiber Channel. Le iSCSI, le AoE ainsi que d'autres protocoles permettent d'accéder à ces périphériques de façon transparente et sans matériel supplémentaire.

GPT

Les disques atteignent couramment une taille de 2To. Le format de partition actuel ne permet pas d'utiliser le disque au delà de cette taille. Il devient donc rapidement obligatoire de passer au format GPT. Ceci implique des modifications dans le bios et dans le système d'exploitation.

Secteur 4k

Les secteurs de 512 octets devenant petit, on commence à fabriquer des disques ayant des secteurs de 4ko. Cela permettra une plus grande capacité, de meilleures performances, mais implique aussi des changements au niveau du bios et de système d'exploitation (très lourd cette fois). Quelques références et solutions.

Filesystem

Toutes ces fonctionnalités nouvelles peuvent êtres prises en compte au niveau du système de fichier pour permettre des fonctionnalités sympathiques. Le snapshot fréquent voir continu, l'utilisation de plusieurs disques locaux voire distants, la vérification d'intégrité en live, la récupération d'une perte sans downtime, la possibilité d'utiliser des disques d'une taille quasiment infinie pour notre époque, l'usage d'un même filesystem par plusieurs machines ...

Tout ceci n'était qu'un aperçu qui je l'espère vous donnera envie de connaître les nouvelles technologies à venir.

Si vous avez aimé, il y a aussi :

1. Lecture d’image disque
2. Disque dur
3. Table des partitions

Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Raid 1

Le choix de ceux qui ne veulent pas de pertes.

Tous les disques sont des copies intégrales. L'avantage le plus important est que lors de la perte d'un disque tout fonctionne comme si de rien n'était. On peut donc remplacer ce disque (ou pas :-).

Un autre avantage existe lors des lectures non séquentielles (lors de la lecture de 2 fichiers par exemple), dans ce cas il est possible d'utiliser un disque pour chaque lecture et donc d'accélérer ce type de lecture. Par contre la lecture d'un seul gros fichier n'est pas accélérée (sous linux).

Il n'y a en revanche aucun impact sur l'écriture, c'est le disque le plus lent qui détermine la vitesse d'écriture (la vitesse devrait être à peu près identique pour chacun).

Notez qu'on peut faire du raid 1 avec plus de 2 disques.

Le Raid 1 peut être matériel, logiciel avec le driver md ou logicielle avec LVM (support du miroring), enfin il est possible de faire du raid1 réseau avec drbd.

Raid 5

Le choix des économes.

En raid 5 chaque disque est découpé en bande, pour chaque groupe de bandes situées au même endroit des disques, une des bandes est choisie pour contenir des octets de redondance (la différence avec le 4 c'est le choix de la bande). Ainsi ce type de raid peut survivre au crash d'un des disques (la redondance permet de reconstruire la bande manquante), mais pas de plusieurs.

L'avantage du raid 5 est que lorsqu'on a de nombreux disques on économise des disques de redondance en n'en achetant qu'un pour la redondance et les autres pour les données.

Mais le raid 5 est assez limité en performances. La lecture se passe comme pour le raid 1. Par contre l'écriture nécessite la lecture de chacune des bandes d'un groupe pour écrire la bande de données, puis calculer et écrire la bande de redondance. C'est donc très lent, à éviter pour les bases de données actives.

D'autre part, lors du crash d'un disque, toutes bandes des disques doivent être lues pour reconstituer une bande manquante. Ce qui implique des baisses de performances énormes, auxquelles il faut ajouter la baisse de performances due à la reconstruction du disque qu'on va remettre. Comme les disque tournent à fond, il n'est pas rare de voir un autre disque exploser en vol à ce moment là -> fin des données.

Le raid 5 peut être matériel ou logiciel avec le driver md de linux.

Raid 6

Le choix des très gros disques.

Le raid 6 fonctionne de la même façon que le raid 5 mais ajoute un deuxième disque de redondance. Ce ne sont pas simplement les données de redondance qui sont dupliquée, mais le calcul qui est différent, toutefois le concept est identique.

Le raid 6 soufre des mêmes inconvénients que le raid 5, il utilise même un disque de plus donc est un peu plus cher, de plus cela provoque une écriture supplémentaire pour chaque groupe de bandes.

Mais le raid 6 résiste au crash de 2 disques, ce qui est intéressant lorsque les disques sont assez gros et que la reconstruction du raid comment à être assez longue (et donc le risque de perte plus gros).

Le raid 6 peut être matériel ou logiciel avec le driver md de linux.

Raid 10

Le choix des riches.

Le raid 10 consiste à accumuler plusieurs raid 1 avec du raid 0 pour en augmenter la taille et les performances.

Le raid 10 offre les avantages simultanés du raid 1 et du raid 0. La perte d'un disque n'empêche pas le raid de tourner et l'utilisation de plusieurs disques en striping permet d'augmenter les performances de lectures.

Le seul inconvénient, c'est qu'il coûte deux fois le prix du raid 0.

Il peut se faire en matériel ou logiciel, md ou lvm.

Raid 0+1

Le mauvais choix.

Le raid 0+1 consiste à mettre 2 raid 0 en parallèle pour les redonder avec du raid 1. On pourrait croire que c'est la même chose que du raid 10, mais non. Et même si certains veulent vous faire croire que les performances sont meilleures, il n'en est rien.

Mais surtout imaginez un instant la perte d'un disque. Dans ce cas un des raid 0 sous-jacent est perdu. Il faut donc le recréer avec un nouveau disque (ce qui est à peu près instantané puisqu'on le laisse vide), puis reconstruire le raid 1 situé au dessus. Et cette deuxième partie va être longue puisqu'elle doit être faite sur la taille totale du raid 0, contrairement au raid 10 qui ne l'aurait fait que sur la taille totale du disque perdu.

Petit récapitulatif

Si vous avez aimé, il y a aussi :

1. Que faire et ne pas faire en raid
2. LaVoMatic
3. L’avenir du disque

J'ai déjà fait des articles sur LVM. Aujourd'hui parlons de snapshot en ram et d'une nouveauté du noyau 2.6.33, le snapshot-merge.

Snapshot en RAM

Tout comme il est possible de faire un LV en RAM, il est possible de faire un snapshot en RAM.

Pour faire un LV (Logical Volume) en RAM : il suffit d'utiliser un ramdisk comme PV(Physical Volume).

$ pvcreate /dev/rd0
$ vgcreate myvg /dev/rd0
$ lvcreate -l 100%FREE -n mylv myvg

Pour faire un snapshot en RAM :

$ pvcreate /dev/rd0
$ vgextend myvg /dev/rd0
$ lvcreate -L 100M -s -n mysnapshot /dev/myvg/mylv

Mais pour quoi faire ? Pour la même chose qu'un livecd : transformer un périphérique en lecture seule en périphérique lecture-écriture qui perdra toutes ses modifications au prochain reboot.

Seul inconvénient, les ramdisk ont une taille prédéfinie au démarrage du noyau (ramdisk_size=).

Mais j'ai gardé le meilleur pour la suite.

Snapshot de test

Maintenant qu'une nouvelle fonctionnalité a été ajoutée au noyau vous allez enfin pouvoir faire les snapshot dont vous aviez toujours rêvé.

Avant il y avait le snapshot qu'on pouvait créer, puis détruire. Selon que l'on travaillait sur le snapshot ou sur la partition originale la destruction nous ramenait à la nouvelle version ou à l'ancienne sans possibilité de choisir entre les 2 une fois le premier octet écrit. Maintenant avec le snapshot merge, il est possible de supprimer un snapshot en réimportant les données qu'il contenait dans la partition originale. Ce qui veut dire qu'on peut choisir.

Prenons un exemple parce que là j'ai franchement mal expliqué.

Toto est un sysadmin prudent, il ne fait jamais de mise à jour du système sans être sûr que ça ne posera pas de problème. Aujourd'hui on lui demande de faire une mise à jour importante, mais il ne sait pas quelles en seront les conséquences. En bon sysadmin il a déjà un noyau à jour et par chance son système est tout en LVM. Hop une synchro (rsync), un snapshot (ou plusieurs, il a bien séparé ses partitions ...), on prévient que ca peut casser et c'est parti, upgrade !

Maintenant 2 choix sont possibles :

• Ça marche ! Alors il suffit de supprimer le snapshot et on n'entendra plus parler de l'ancienne version.
• Ça merde ! Hop un petit snapshot-merge et on revient à l'ancienne version comme si de rien n'était. (lvconvert --merge)

Et voilà ! Maintenant vous pouvez faire vos mises à jour en toute sérénité ! En fin presque : on parle de la racine et donc de nombreux fichiers en cours d'utilisation sur la partition en question, ce qui veut dire reboot pour pouvoir terminer le merge. Mais le merge peut quand même se faire en live (vous pouvez déjà utiliser la partition pendant que le merge se termine en arrière plan). Il est donc possible de lancer la commande de merge, modifier son fstab si besoin et de rebooter.

Enfin n'oubliez pas une chose, les snapshot lvm ne fonctionnent qu'au niveau block device, c'est-à-dire en dessous du système de fichiers. C'est comme si vous enleviez le disque sans éteindre la machine, il se peut que le système de fichier ne soit pas au mieux de sa forme au moment ou vous le lancez, ayez au moins un système journalisé pour éviter les surprises et jouez du sync pour un peu plus de garanties.

Rien ne vaudra jamais les snapshot au niveau du système de fichier comme chez ZFS ou le futur BTRFS.

Si vous avez aimé, il y a aussi :

1. Snapshot de snapshot
2. Les Vauriens M’admirent
3. La carte du périphérique

Un disque dur est en général divisé en partitions. Je dis en général, car ce n'est pas obligatoire, une disquette ne l'est quasiment jamais.

Sur un PC, la table est en général au format DOS (nommé aussi MBR), je dis en général car ce n'est pas le seul format possible, même si c'est le plus courant.

Nous allons donc se restreindre au cas d'un disque dur partitionné au format DOS.

Premier secteur

Les informations de partitionnement se situent sur le premier secteur (512 octets) d'un disque. Mais il n'y a pas que ça. On y trouve des nombres magiques, et du code pour démarre la machine. La table des partitions n'est constituée que de 64 octets (de 446 à 510). On appelle ce secteur le master boot record (MBR).

Pour lire les données de votre MBR :

$ dd if=/dev/hda of=/tmp/mbr bs=512 count=1
$ xxd /tmp/mbr

La table contient 4 entrées de 16 octets, qui forment les fameuses 4 partitions primaires, limite originelle du nombre de partitions.

Chaque entrée décrit le début, la longueur et quelques attributs d'une partition. Historiquement, on utilisait la notion de cylindre, tête et secteur mais cette notation est obsolète, inefficace en terme de place et ne correspond plus à la réalité. On utilise donc un comptage sur 4 octets du nombre de secteurs (512 octets) sur le disque, qu'on appelle LBA. Comptez, cela fait 2To maximum, vous aurez peut-être un problème de partitionnement avec votre prochain disque, il faudra passer à un format un peu plus moderne ... patientez pour un prochain article.

Maintenant, je suis sûr que vous voulez savoir à quoi ressemble votre table :

# Contenu quasiment brut
$ sfdisk -d /dev/hda
# le même un peu traduit
$ sfdisk -l -uS /dev/hda

Et là vous vous dites : mais il y a plus que 4 partitions !

Les partitions logiques et étendues

Hé oui, des gens ont voulu pouvoir avoir bien plus que 4 partitions, c'est comme ça qu'on a inventé les partitions logiques. Question vocabulaire, une partition étendue est une partition primaire qui va contenir d'autres partitions qu'on appelle les partitions logiques.

Donc si vous lisez bien votre table, il est probable qu'elle contienne un hda2 (étendue, non visible sous linux) englobant la totalité du disque à l'exception de la première partition. Les partitions hda5 et hda6 (logiques) sont alors dans cette dernière.

Le format de partition étendue est un peu consommateur (512 octets) puisqu'on réécrit un nouveau secteur pour chaque partition au même format que le MBR. On n'y met cette fois que la partition logique et la description de la prochaine partition (ce qui forme une liste chaînée). Cela veut dire qu'on peut avoir autant de partitions étendues qu'on veut (par défaut linux n'en peut gérer que 64).

Espace perdu

Comme dit un peu plus haut, historiquement on utilisait la notation C/H/S (cylinder, head, sector) pour décrire les positions des partitions. Cette notation impliquait qu'on mette la première partition dans la 2e piste puisque le MBR se trouvait dans la première. On a gardé cette convention même si elle n'a rien d'obligatoire. Ce qui laisse de l'espace libre dans la première piste.

Une piste est constituée des secteurs d'un cylindre sur une tête de lecture. Ce qui nous donne :

• Taille Secteur = 512 (défaut sur quasiment tous les disques)
• Taille Piste = 512 * nombre de secteurs par piste (S)
• Taille Cylindre = 512 * nombre de secteurs par piste (S) * nombre de têtes (H)
• Taille du disque = 512 * nombre de secteurs par piste (S) * nombre de têtes (H) * nombre de cylindre (C)

Elle a en général une taille de 512*63 soit 32256 octets inutilisés sur un disque (et autant pour chaque partition logique si vous avez bien suivi). C'est ici que certains outils anti-piratage mettaient leurs données à l'époque où windows existait encore. Maintenant un bootloader comme grub va profiter de cet espace pour s'y loger et éviter d'être dérangé par les systèmes.

Grub premier du nom va y mettre son stage1.5 et grub2 est capable d'y rentrer en entier.

Si vous avez aimé, il y a aussi :

1. Lecture d’image disque
2. Forcer la relecture des partitions
3. L’avenir du disque

Même si la plupart des distributions sont passées à grub, on s'est longtemps posé la question d'utiliser lilo ou grub. Il servent tous les deux à charger linux (le noyau), voyons comment ça marche.

Bios

Avant de nous intéresser au bootloader, étudions le processus de démarrage d'une machine (x86 type intel).

1. Appui sur le bouton
2. Allumage de l'alimentation, électricité dans la carte mère
3. Allumage du processeur dans un état connu
4. Passage du contrôle au bios
5. Lecture d'un disque, chargement du secteur de boot nommé MBR (généralement un bootloader)
6. Chargement du noyau et d'éventuels modules, passage du contrôle au noyau
7. Montage d'un système de fichier et passage du contrôle au processus d'init (sur les unix)

Bon, le début, vous connaissez.

L'état connu du processeur c'est : mode réel, 16bits, exécution pointant sur les derniers octets du premier Mo (FFFF:0000). Ici se trouve mappé statiquement le bios qui va se lancer et initialiser le matériel qu'il connaît. Il laisse disponible quelques fonctions via des interruptions, par exemple pour accéder à la carte vidéo ou au disque dur. Et il termine en chargeant le premier secteur (512 octets) du premier périphérique (disque, dur, clé usb ...) bootable qu'il trouve et lui passe la main (à l'adresse 0000:7C00).

C'est ici qu'on trouve lilo, grub, syslinux et même parfois linux lui-même sur de vieilles versions. Comme vous le constatez, 512 octets c'est très petit pour coder un bootloader (surtout que les octets ne sont pas tous disponibles à cause de la table des partitions). C'est pourquoi les bootloaders ont tous une architecture un peu bizarre avec plusieurs étapes.

Lilo

Lilo est un bootloader spécifique à linux (LInux LOader). Il fonctionne en 2 temps, un secteur de boot qui va charger un fichier un peu plus gros dont il connaît les secteurs sur le disque. Ce dernier peut éventuellement proposer un menu puis charge le bon noyau et lui passe la main.

Lilo utilise un fichier de configuration /etc/lilo.conf. À chaque modification de ce fichier, il faut lancer la commande lilo. Cette commande va lire le fichier et réécrire le secteur de boot à la racine du disque. Il va aussi écrire un fichier map qui contient la liste des secteurs sur le disque où trouver les étapes suivantes de chargement ainsi qu'une version compilée du fichier de configuration. En pratique cette deuxième étape se trouve à l'intérieur du binaire lilo lui-même (depuis la version 22.x x<4).

Grub

Grub est un bootloader qui se veut générique (la version 2 commence à être utilisable sur d'autres architectures). Il est capable de booter de nombreux formats de noyaux.

Son secteur de boot (stage1) est statique et est installé une fois pour toutes (ou presque). Celui-ci se contente de charger un autre fichier (stage2) qui sait lire les systèmes de fichiers et donc peut lire sa propre configuration directement. Cela lui permet de ne pas nécessiter de manipulation après chaque modification de sa configuration. Il est aussi beaucoup plus flexible puisque cette deuxième étape contient un shell qui permet de choisir soi-même ce qui se passe pendant le boot (pratique pour les récupérations d'urgence).

La limitation de cette technique est qu'il faut encore réinstaller grub dans le secteur de boot lorsque le shell (stage2) a été modifié. Mais on peut faire mieux, il existe la possibilité d'ajouter une étape, le stage1.5, qui sait lire un système de fichier. Ce code est suffisamment petit pour qu'on puisse l'installer dans un espace vide du disque juste derrière la table des partitions. Il est donc dans un endroit qui ne bougera jamais et il saura lire le shell où qu'il soit et aucune réinstallation ne sera plus nécessaire.

Il reste tout de même un cas où il faut le réinstaller : quand on change le type de système de fichier ou la partition qui contient le shell grub.

Travaux pratiques

Nous allons nous exercer sur un loopback (un disque virtuel) pour éviter les larmes en cas d'erreur (ayez toujours un liveCD sur vous, on ne sait jamais). Installez aussi qemu, ça vous permettra de tester ce que vous faites (c'est pratique même sur des vrais disque pour ne pas rebooter).

Préparation du disque virtuel pour nos tests :

# 50Mo c'est déjà beaucoup pour un disque :-)
$ dd if=/dev/zero of=/tmp/test bs=1M count=50
# Le disque entier
$ losetup /dev/loop0 /tmp/test
# On le partitionne (une partition, tout l'espace)
$ cfdisk /dev/loop0
# On repère le premier secteur de la partition
$ fdisk -l -u /dev/loop0 # -> start, en général 63
# On transforme cette partition en device 
$ losetup -o $((63*512)) /dev/loop1 /tmp/test
# On crée un système de fichier sur cette partition
$ mke2fs /dev/loop1
# On le monte 
$ mount /dev/loop1 /mnt
# On y place un noyau pour faire joli
$ cp /boot/vmlinuz-* /mnt
# on fait un test avec qemu pour vérifier que ça ne marche pas
$ sync # pour ne pas avoir à démonter la partition
$ qemu /tmp/test

Vous aurez aussi besoin de grub et lilo, mais votre système ne vous permettra pas d'installer les deux en même temps. Alors vous pouvez soit les recompiler, soit lire les récupérer sous forme binaire, soit sauter la partie correspondante :-). Pour les debianistes :

$ aptitude download lilo
$ dpkg -x lilo*.deb ~/tmp/

Lilo

Créons nous un fichier de configuration pour notre noyau (/mnt/etc/lilo.conf) :

# définition de la correspondance bios <-> linux
disk=/dev/loop0
        bios=0x80
        sectors=63
        cylinders=12
        heads=255
        partition=/dev/loop1
                start=63

# où mettre le secteur de boot
boot=/dev/loop0
# disque dur moderne
lba32
# on demande a l'utilisateur son avis
prompt
# avec un menu c'est plus joli
install=menu
# on stocke la liste des secteurs quelque part sur la partition
map=/mnt/lilo/map
# on ne seuvegarde pas le secteur de boot
backup=/dev/null

# une seule entrée dans notre menu
image=/mnt/vmlinuz-2.6.25
        label=Mon beau noyau, roi des os ...

Vous aurez remarqué le premier paragraphe. Il n'est nécessaire que parce que nous travaillons sur des loopbacks. Il s'agit d'expliquer à lilo que lors du boot, le bios (et donc lilo) verra ce qui est actuellement /dev/loop0 comme le premier disque (0x80). On lui indique aussi comment il est partitionné puisqu'il ne peut pas deviner tout seul que /dev/loop1 est sur le disque /dev/loop0. Et enfin on lui indique la géométrie du disque telle que nous l'a donnée la commande fdisk un peu plus haut car un loopback n'a pas de géométrie.

Le reste du fichier est le minimum pour avoir quelque chose de correct qui ne casse pas votre machine et qui propose une entrée de menu. Pour plus de fioritures, vous pouvez regarder la documentation vraiment bien détaillée. Vous pouvez vous amuser à mettre des images, ou même un boot animé, il y a même un boot casse briques.

Et maintenant installons lilo :

# on a défini ce répertoire dans lilo.conf (d'habitude on met /boot)
$ mkdir /mnt/lilo
# on met à jour le bootloader
$ lilo -c /mnt/etc/lilo.conf
# et on teste pour faire joli
$ sync && qemu /tmp/test

Wahoo, c'est beau ! Maintenant, faisons de même avec ...

Grub

Nous pourrions jouer la facilité et lancer grub-install. Mais non, ce n'est pas notre genre. Il faut comprendre comment ça marche avant de tout casser. Tout comme il faut savoir calculer avant de se servir d'une calculatrice.

Commençons par l'indispensable, un fichier de configuration :

# une entrée, c'est déjà bien assez
title Mon Bô noyau, que j'aime ta verdure 
kernel (hd0,0)/vmlinuz-2.6.25

Vous remarquerez deux choses. Tout d'abord grub utilise sa propre notation pour les disques et partitions (hé oui linux ne sera plus là quand il bootera). (hd0) est le premier disque vu par le bios, (hd1) le 2e, etc. De même pour les partitions, (hd0,0) est la première partition du premier disque, (hd0,1) la 2e etc. Ensuite, le chemin est relatif à la partition telle qu'elle sera lue au boot et non pas à l'arborescence actuelle (on ne met pas /mnt/vmlinuz-2.6.25).

Le stage2 (le shell) doit être disponible sur le nouveau disque pour que le boot fonctionne.

$ mkdir /mnt/grub
$ cp /boot/grub/stage2 /mnt/grub/

Créons un fichier device.map pour faire correspondre les loopback aux disques qui seront vus par le bios (même problème que pour lilo) :

(hd0) /dev/loop0
(hd1) /dev/hda

Le hd1 est bien utilecar on va lire des fichiers qui ne sont pas stockés sur le loopback (on pourrait aussi les y copier :-).

Ensuite lançons un shell grub pour faire l'installation :

$ grub --device-map=/tmp/device.map
# on met un stage1.5 pour être complet
# il se trouve sur /dev/hda1 dans /boot/grub et on le met sur /dev/loop0 
$ embed (hd1,0)/boot/grub/e2fs_stage1_5 (hd0)
> 15 sectors are embedded.
# on va installer le stage1 et paramétrer tout ça :
#   --stage2=... parce que la partition est montée, il faut écrire dessus en utilisant le noyau
#   (hd1,0)/boot/grub/stage1 : on va chercher le stage1 où il est stocké actuellement
#   (hd0) : on installe sur le mbr de /dev/loop0
#   (hd0)1+15 : on lui dit d'utiliser le stage1.5 installé précédemment (mbr+1, 15 secteurs) pour lire le stage2
#   p (hd0,0)/grub/stage2 : on dit au stage1.5 où trouver le stage2
#   /grub/menu.lst : on dit à stage2 où aller chercher sa configuration
$ install --stage2=/mnt/grub/stage2 (hd1,0)/boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/menu.lst
$ quit

Remarquez le embed, il met le stage 1.5 dans l'espace disponible derrière la table des partitions comme nous l'avons déjà vu.

Si vous vouliez sauter le stage1.5 cela aurait donné :

$ grub --device-map=/tmp/device.map
$ install --stage2=/mnt/grub/stage2 (hd1,0)/boot/grub/stage1 (hd0) (hd0,0)/grub/stage2 /grub/menu.lst
$ quit

Et comme je suis gentil, je vous montre comment le faire sans s'embêter (et sans hd1) :

$ cp -r /boot/grub /mnt
$ grub --device-map=/mnt/grub/device.map
$ setup --stage2=/mnt/grub/stage2 (hd0) (hd0,0)
$ quit

Et si vous voulez installer grub pour le système en cours d'exécution il y a encore plus simple :

$ grub-install /dev/hda

Test :

$ sync && qemu /tmp/test

Ça y est ! La gloire est à nos portes !

Choix

Et maintenant, lequel choisir ? Cela dépend de votre situation et de vos besoins. Faisons un petit résumé des avantages de chacun.

Grub:

• peut lancer plus de systèmes
• dispose d'un shell au boot pour les réparations ou les changements de paramètres
• résiste aux modifications du système de fichier

Lilo :

• plus léger
• sait contourner les bugs d'un grand nombre de vieux bios

C'est ce qui fait que grub est de plus en plus souvent choisi comme bootloader face à lilo.

Si vous avez aimé, il y a aussi :

1. Processus de boot
2. Table des partitions
3. Réinstallation distante

Maintenant que vous savez comment fonctionne device-mapper, il est possible de compenser un certain manque de lvm à la main. Nous allons faire des snapshot de snapshot (merci à glandium pour la suggestion).

Voici 2 scripts permettant de faire cela. Ils s'utilisent de la manière suivante :

# En supposant que vous ayez déjà fait un premier snapshot avec lvm
# snapshot2 sera un snapshot de snapshot1
$ mysnapshot '-L 1G' vg0 snapshot1 snapshot2

# Pour supprimer le snapshot précédemment créé
$ mysnapshotrm vg0 snapshot2

Prenez ces scripts avec quelques pincettes puisque bien que testés sur mes machines, ils n'est pas garanti qu'ils fassent tout ce que vous vouliez. Par exemple, il permet d'enchaîner les snapshot, mais tel quel il va vous poser quelques problèmes pour faire des arbres de snapshot (plusieurs fois un snapshot d'un même snapshot), dans ce cas ... à vous de bosser.

Attention : contrairement à lvm, ces snapshots ne sont pas automatiquement mis en place au boot.

Un petit schéma du principe de fonctionnement des snapshots, peut-être un peu plus clair que le précédent pour ceux qui connaissent device-mapper (attention, les noms ne correspondent pas totalement à ceux du script).

Ce schéma permet aussi d'expliquer quelque chose que j'ai oublié de dire lors de l'article précédent : bien qu'il n'y ait pas de différence fondamentale entre l'orginal et le snapshot, le snapshot est le périphérique qui aura les meilleures performances en écriture.

mysnapshot :

#!/bin/sh 

# gestion des paramètres
if [ -z "$4" ]
then
        echo "usage $0 'lvmParameters' volumeGroup origin snapshot"
        exit 1
fi

lvmparams=$1
vg=$2
origin=$3
snapshot=$4

min=0
# lecture du snapshot existant pour déterminer la taille du dev final
idh=$(stat -c "%T" /dev/mapper/$vg-$origin)
id=$((0x$idh))
max=$(cat /sys/devices/virtual/block/dm-$id/size)

# on crée avec lvm l'espace pour stocker le snapshot
lvcreate -n $snapshot-cow $lvmparams  $vg

# on suspend le snapshot pour que l'activité en cours dessus ne le casse pas
dmsetup suspend $vg-$origin

# on recopie le snapshot d'origine dans un un nouveau dev (pour y accéder directement et pour le retour en arrière)
dmsetup table $vg-$origin | dmsetup create $vg-$origin-real

# on remplace le snapshot d'origine par un device qui va générer des évènements de modif (pour le 2e snapshot)
echo $min $max snapshot-origin /dev/mapper/$vg-$origin-real | dmsetup reload $vg-$origin

# on crée le nouveau snapshot qui pointe vers l'espace de stockage et vers le snapshot d'origine
echo $min $max snapshot /dev/mapper/$vg-$origin-real /dev/mapper/$vg-$snapshot--cow P 8 | dmsetup create $vg-$snapshot

# on réactive le snapshot d'origine qui est maintenant snapshotté
dmsetup resume $vg-$origin

mysnapshotrm :

#!/bin/sh

# gestion des paramètres
if [ -z "$2" ]
then
        echo "usage $0 volumeGroup snapshot"
        exit 1
fi

vg=$1
snapshot=$2

# lecture du dev du snapshot pour découvrir qui était l'original
originmm=$(dmsetup table $vg-$snapshot | cut -d " " -f 4 | sed 's/:/,[[:space:]]+/')
originvg=$(ls -l /dev/mapper | egrep "$originmm" | sed 's/.* \([^ ]*\)$/\1/')
origin=$(echo $originvg | sed "s/$vg-\(.*\)-real/\1/")

# on suspend le snapshot d'origine pour éviter de le casser
dmsetup suspend $vg-$origin

# on le restaure avec la version d'origine
dmsetup table $vg-$origin-real | dmsetup reload $vg-$origin

# et on peut le réactiver
dmsetup resume $vg-$origin

# on vire le snapshot créé
dmsetup remove $vg-$snapshot

# on vire la copie du snapshot d'origine
dmsetup remove $vg-$origin-real

# et on supprime l'espace de stockage de notre snapshot
lvremove -f /dev/$vg/$snapshot-cow

Et si vous êtes développeur lvm, si vous pouviez y intégrer l'équivalent, ça serait sympa.

Si vous avez aimé, il y a aussi :

1. Snapshot temporaires
2. La carte du périphérique
3. Faire du chiffre

Maintenant que vous savez tout sur device mapper, il y a une dernière fonctionnalité fournie en standard que vous allez vouloir utiliser: le chiffrement des partitions. Comme vous l'avez compris, il est possible de tout faire avec dmsetup, mais il y a mieux et c'est moins cher.

Chiffrement avec LUKS

Attention, ce que nous faisons ici écrit sur la partition, si vous ne voulez pas perdre vos données, regardez le dernier paragraphe.

La commande cryptsetup s'occupe de tout pour vous. Pour chiffrer une partition :

# pour préserver la résistance de votre partition à la cryptanalyse (des données apparemment chiffrées déjà sur le disque)
# on efface la partition avec des données aléatoires
$ dd if=/dev/urandom of=/dev/sda1
# il vous demandera simplement une passphrase
$ cryptsetup luksFormat /dev/sda1

Et maintenant pour l'utiliser :

# il vous demandera simplement une passphrase
$ cryptsetup luksOpen /dev/sda1 partoche

Et voila, votre partition est disponible dans /dev/mapper/partoche. Vous pouvez en faire ce que vous voulez, mettre une système de fichier dessus ou le redécouper avec lvm ou écrire directement dessus ...

Et si vous ne voulez plus utiliser la partition, fermez-là (la partition) pour ne pas qu'un autre tente d'en lire le contenu, on ne sait jamais :

$ cryptsetup luksClose partoche

Un peu plus loin

Cryptsetup permet d'autres formats de disque que LUKS, mais il n'est pas intéressant de les utiliser car luks est disponible un peu partout (même sous windows) et bien pensé

Luks permet entre autre quelques fantaisies comme la possibilité d'utiliser plusieurs clés, ce qui veut dire que vous pouvez partager un disque dur chiffré entre plusieurs personnes et que chacun ait sa clé pour lire et écrire dessus.

# ajoute une nouvelle clé (nouvel utilisateur ?)
$ cryptsetup luksAddKey /dev/sda1

Et donc vous pouvez révoquer une clé pour interdire à un des participants d'y revenir :

# liste les clés
$ cryptsetup luksDump /dev/sda1
# on en révoque une 
$ cryptsetup luksDelKey /dev/sda1 1

Attention si un des utilisateurs a eu accès aux méta-données de la partition, il a très bien pu les enregistrer, et comme il a du garder sa propre clé, il est dans ce cas toujours capable d'utiliser le disque.

Un autre usage des clés multiples est d'avoir une clé d'usage et une clé de secours imprimée et stockée dans un coffre pour usage en cas de perte de la première.

Types de chiffrement

Vous pouvez choisir le type de chiffrement utilisé au moment de la création de la partition. Par exemple si vous ne faites pas confiance au NIST, vous pourriez préférer la méthode twofish.

# connaître la liste des chiffrements disponibles (attention, tous ne sont pas des chiffrement)
$ cat /proc/crypto
# charger un type manquant
$ modprobe twofish
# utiliser le bon type
$ cryptsetup luksFormat --cipher twofish /dev/sda1

Encore plus loin

Il est même possible de chiffrer une partition sur elle même sans casser ce qui se trouve dessus. Seul problème, il faut qu'elle dispose d'un peu de place pour les en-têtes luks. Cette taille est variable, en fonction de la taille choisie pour la clé. Mais elle est de l'ordre de 500 ko avec les essiv, si besoin faites un test préalable.

Supposons qu'il y a un système de fichier (fort probable :)

# on démonte
$ umount /dev/sda1
# on réduit de 1Mo (ça devrait suffire dans la plupart des cas)
$ resize2fs /dev/sda1 9999M

On stocke dans un coin l'endroit ou sera notre en-tête

# 1Mo aussi 
$ dd if=/dev/sda1 of=/tmp/first bs=1M count=1

On fait notre partition chiffrée

# on prépare la partition
$ cryptsetup luksFormat /dev/sda1
# on la met en place
$ cryptsetup luksOpen /dev/sda1 crypto1

Et là, il y a plusieurs subtilités, on va recopier /dev/sda1 dans /dev/mapper/tmp. Ça fonctionne parce que ce qu'on va lire va être lu avant qu'on écrive au même endroit. Cet argument n'est pas tout à fait valable puisqu'on va recopier un peu plus loin qu'on ne va lire (header oblige). Donc la deuxième subtilité sera de recopier en commençant par la fin pour ne pas écraser les données qu'on va lire à la prochaine itération.

# on récupère le décalage a effectuer (unité le bloc (512o)
$ cryptsetup luksDump /dev/sda1 | grep Payload
> Payload offset: 1032
$ offset=$((1032*512))
# on récupère la taille de la partition : 
$ blockdev --getsize64 /dev/sa1
> 67108864
$ max=67108864

# et on fait la copie morceaux par morceaux en partant de la fin
$ i=$(($max/$offset))
$ while [ $i -gt 0 ]
 do
     dd if=/dev/sda1 of=/dev/mapper/crypto1 bs=$offset count=1 seek=$i skip=$i
     i=$(($i-1))
 done
# et on n'oublie pas notre premier morceau
$ dd if=/tmp/first of=/dev/mapper/crypto1

Ça y est, notre partition chiffrée /dev/mapper/crypto1 est prête à être utilisée comme avant

$ mount /dev/mapper/crypto1 /srv

Encore une victoire de canard !

Et pour plus de détails, le site sur dm-crypt et sur luks vous expliquera tout.

Si vous avez aimé, il y a aussi :

1. La carte du périphérique
2. En vrac (13)
3. Clé privée