LVM/fr

LVM (Logical Volume Manager - Gestionnaire de volumes logiques) permet aux administrateurs de créer des méta-périphériques qui fournissent une couche d'abstraction entre un système de fichiers et le stockage physique sous-jacent. Les méta-périphériques (sur lesquels sont placés les systèmes de fichiers) sont des volumes logiques, qui utilisent de l'espace de stockages tiré de pools de stockage appelés groupes de volumes. Un groupe de volumes dispose d'un ou plusieurs volumes physiques qui représentent les véritables périphériques sur lesquels les données sont stockées.

Les volumes physiques peuvent être des partitions, des disques durs SATA entiers regroupés sous formes de JBOD  (Just a Bunch Of Disks - Un simple groupe de disques), des systèmes RAID, iSCSI, un canal de fibre, eSATA etc.

Installation
La configuration de LVM est gérée à la fois par des pilotes au niveau du noyau et des applications de l'espace utilisateur.

Noyau
Activez les options suivantes du noyau:

Logiciel
Installez le paquet :

Configuration
La configuration de LVM se fait à plusieurs niveaux:
 * 1) Gestion de LV, PV et VG via l'utilitaire de gestion
 * 2) Peaufinage du sous-système LVM via les fichiers de configuration
 * 3) Gestion du service au niveau de la distribution
 * 4) configuration via un disque virtuel de démarrage

La gestion des volumes physiques et logiques, tout autant que celles des groupes de volumes est traitée dans le chapitre  Usage.

Fichiers de configuration de LVM
LVM dispose d'un fichier de configuration très étendu, soit. La plupart des utilisateurs n'ont pas besoin de modifier les paramètres de ce fichier pour commencer à utiliser LVM.

Gestion du service
Gentoo fournit le service LVM pour détecter automatiquement et activer les groupes de volumes et les volumes logiques.

Le service peut être géré via le système init.

openrc
Pour démarre LVM à la main :

Pour démarrer LVM au démarrage de la machine.

systemd
Pour démarrer lvm à la main

Pour démarrer LVM au démarrage de la machine.

Utilisation de LVM dans un disque virtuel de démarrage -- initramfs
La plupart des chargeurs d'amorçage ne peuvent pas démarrer depuis LVM directement - Ni GRUB patrimonial, ni LILO ne le peuvent. GRUB2 peut amorcer depuis un volume logique linéaire, un volume logique miroir et possiblement depuis quelques volume logiques RAID. Aucun chargeur d'amorçage ne prend actuellement en charge les volumes logiques minces.

Pour cette raison, il est conseillé d'utiliser une partition de démarrage (boot) non LVM et de monter la racine LVM depuis un système de fichiers virtuel de démarrage (initramfs). Un tel système de fichiers virtuel peut être généré automatiquement via genkernel, genkernel-next et dracut:


 * genkernel ne peut pas amorcer depuis tous les types sauf depuis les volumes minces (puisqu'il ne compile/construit ni ne copie les binaires des outils thin-provisionning (founiture mince) de l'hôte de compilation/construction) et peut-être RAID10 (la prise en charge de RAID10 nécessite LVM2 2.02.98, mais genkernel compile 2.02.89, néanmoins si des binaires statiques sont disponibles, il peut les copier)
 * genkernel-next ne peut pas amorcer depuis tous les types volumes, mais a besoin d'un paquet app-misc/pax-utils suffisamment récent sous peine de voir les binaires thin (minces) cassés (voir )
 * dracut devrait amorcer tous les types, mais n'inclut que la prise en charge thin dans le système de fichiers virtuel de démarrage (initramfs) si l'hôte sur lequel on l'exécute à une racine thin (mince).

Genkernel/Genkernel-next
Installez le paquet ou le paquet. L'option static de la variable USE doit aussi être activée sur le paquet   de façon à ce que genkernel utilise les binaires système (autrement il construirait sa propre copie privée). L'exemple suivant construit seulement un système de fichiers virtuel de démarrage (pas un noyau entier) et active la prise en charge de LVM.

La page de manuel de genkernel présente d'autres options qui dépendent des besoins du système.

Le disque virtuel de démarrage (initrd) demande certains paramètres pour savoir démarrer lvm. Ils lui sont fournis de la même manière que les autres paramètres du noyau. Par exemple :

Dracut
Le paquet, qui a été porté depuis le projet RedHat, tient lieu d'outil similaire pour générer un système de fichiers virtuel de démarrage. Comme il est actuellement sous ~arch pour test, les utilisateurs doivent l'accepter explicitement (via  ) avant de l'installer. Avant cela, l'otpion   doit être déclarée dans. D'autres modules peuvent être requis. Reportez-vous à Dracut. En général, la commande suivante devrait générer un système virtuel de fichiers de démarrage utilisable (initramfs).

Le disque virtuel de démarrage requiert quelques paramètres pour le renseigner sur l'endroit où démarrer lvm. Ces derniers sont transmis de la même façon que les autres paramètres du noyau. Par exemple :

Pour une liste exhaustive des options de lvm avec dracut, reportez-vous à la section concernée du manuel de dracut.

Utilisation
LVM organise le stockage sur 3 niveaux différents comme suit :
 * disques durs, partitions, systèmes RAID systems ou autres moyens de stockage sont initialisés en tant que volumes physiques (PVs)
 * les volumes physiques (Physical Volumes) sont regroupés en groupe de volumes (Volumes Groups)
 * les volumes logiques (Logical Volumes) sont gérés en groupes de volumes (VG)

Volumes physiques (Pysical Volumes)
Les volumes physiques sont les systèmes physiques réels sur lesquels LVM est construit.

Partitionnement
Le code du type de partition pour LVM est8e (Linux LVM).

Par exemple, pour définir le type, via, d'une partition  :

Dans, ajoutez une partition en tapant  n (nouvelle) et changez le type de la partition en tapant  t (type) et en saisissant  8e.

Créer un volume physique
Les volumes physiques peuvent être créé et initialisé avec la commande.

Par exemple, la commande suivante crée un volume physique sur la première partition de et :

Lister les volumes physiques
La commande  retourne une vue d'ensemble de tous les volumes physiques du système.

Si plus de volumes physiques devraient être affichés, alors al commande  est capable de détecter les volumes physiques inactifs et peut les activer.

Retirer un volume physique
LVM répartit les données automatiquement sur tous les volumes physiques (sauf si on lui demande de procéder différemment) mais dans une démarche linéaire. Si un volume logique requis (dans un groupe de volumes) est plus petit que le volume de l'espace libre sur un unique volume physique, alors tout l'espace de ce volume physique (unique) est alloué à ce volume logique d'une manière contigüe. Ceci vise à optimiser la performance.

S'il est nécessaire de retirer un volume physique d'un groupe de volumes, les données doivent d'abord être déplacées en dehors de ce volume physique. La commande   permet de déplacer toutes les données d'un volume physique à un autre à l'intérieur d'un même groupe de volumes.

Une telle opération peut prendre beaucoup de temps selon l'importance volumique des données à déplacer. Une fois terminé, il ne devrait rester aucune donnée sur ce périphérique. Vérifiez que le volume physique n'est plus utilisé par un volume logique avec la commande.

L'étape suivante consiste à retirer le volume physique du groupe de volumes. La commande   est là pour cela. Après l'avoir utilisée, le volume peut être détaché du groupe de volumes par la commande  :

Groupe de volumes (Volum Group)
Un groupe de volumes (VG) regroupe un certain nombre de volumes physiques et se présente comme dans le système de fichiers. Le nom du groupe de volumes est choisi par l'administrateur.

Créer un groupe de volumes
La commande suivante crée un groupe de volume appelé vg0 en lui assignant deux volumes physiques et.

Lister les groupes de volumes
La commande  retourne la liste des groupes de volumes actifs:

Si des groupes de volumes n'apparaissent pas, utilisez la commande   pour les localiser :

Étendre un groupe de volumes
Les groupes de volumes regroupent des volumes physiques, permettant ainsi aux administrateurs d'utiliser un pool de stockage pour allouer de l'espace aux systèmes de fichiers. Lorsqu'un groupe de volumes manque de ressources physiques, il est nécessaire de l'étendre en lui ajoutant de nouveaux volumes physiques.

La commande suivante étend le groupe de volumes vg0 en lui ajoutant le volume physique :

N'oubliez pas que le volume physique doit d'abord être initialisé en tant que tel !

Réduire un groupe de volumes
Si des volumes physiques doivent être retiré d'un groupe de volumes, toutes les données encore utilisées de ce volume physique doivent être déplacées vers d'autres volumes physiques à l'intérieur du groupe de volumes. Comme nous l'avons vu précédemment, on utilise pour cela la commande. Après cela, le volume physique peut être retiré du groupe en utilisant la commande  :

Retirer un groupe de volumes
Si un groupe de volumes n'est plus nécessaire (ou en d'autres termes, le pool de stockage qu'il représente n'est plus utilisé et que les volumes physiques qui le composent peuvent être libérés pour une autre utilisation), il peut être retiré avec la commande. Ceci ne fonctionne que si aucun volume logique n'est défini pour ce groupe de volumes, et que si tous les volumes physiques, à l'exception d'un seul, ont été retirés de ce pool.

Volume logique (Logical Volume)
Les volumes logiques sont les méta-périphériques finaux mis à la disposition du système, ordinairement pour y placer des systèmes de fichiers. Ils sont créés et gérés en groupes de volumes et apparaissent sous la forme. Comme avec les groupes de volumes, le nom utilisé pour désigner le volume est fixé par l'administrateur.

Créer un volume logique
La commande   crée un volume logique. Les paramètres passés à la commande sont la taille requise (qui ne peut excéder la taille de l'espace libre dans le groupe de volume), le groupe de volumes à qui l'espace est réclamé et le nom du volume logique à créer.

Dans l'exemple qui suit, un volume logique nommé lvol1 est créé à partir du groupe de volumes nommé vg0 avec une taille de 150MB.

Il est possible de spécifier à la commande  d'utiliser tout l'espace libre d'un groupe de volumes. On utilise pour cela le paramètre -l qui spécifie la taille en nombre d' extents plutôt qu'une taille (interprétable par un humain). Les volumes logiques sont éclatés en logical extents qui représentent des blocs de données dans un groupe de volumes. Tous les extents dans un groupe de volumes possèdent la même taille. Via le paramètre -l, on spécifie à la commande     d'allouer tous les extents libres.

Next to FREE the VG key can be used to denote the entire size of a volume group.

Lister les volumes logiques
Pour lister tous les groupes de volumes, utilisez la commande.

Si des volumes logiques n'apparaissent pas, on peut utiliser la commande   pour détecter tous les volumes logiques dans tous les groupes de volumes disponibles.

Étendre un volume logique
Lorsqu'un volume logique doit être étendu, on peut utiliser la commande   pour étendre l'espace alloué à ce volume.

Par exemple pour augment la taille du volume logique 'lvol1'' jusqu'à 500 MO :

On peut aussi utiliser la taille à ajouter plutôt que de spécifier la taille totale.

Un groupe de volumes ne met pas immédiatement un espace de stockage additionnel à la disposition de l'utilisateur. Pour cela, le système de fichiers qui occupe ce groupe de volumes doit être élargi lui aussi. Tous les systèmes de fichiers ne permettent pas le redimensionnement en ligne. Vérifiez la documentation de votre système de fichier pour plus d'information.

For instance, to resize an ext4 file system to become 500MB in size:

Reduce LV
If a logical volume needs to be reduced in size, first shrink the file system itself. Not all file systems support online shrinking.

For instance, ext4 does not support online shrinking so the file system needs to be unmounted first. It is also recommended to do a file system check to make sure there are no inconsistencies:

With a reduced file system, it is now possible to reduce the logical volume as well:

LV Permissions
LVM supports permission states on the logical volumes.

For instance, a logical volume can be set to read only using the  command:

The remount is needed as the change is not enforced immediately.

To mark the logical volume as writable again, use the rw permission bit:

Remove LV
Before removing a logical volume, make sure it is no longer mounted:

Deactivate the logical volume so that no further write activity can take place:

With the volume unmounted and deactivated, it can now be removed, freeing the extents allocated to it for use by other logical volumes in the volume group:

Features
LVM provides quite a few interesting features for storage administrators, including (but not limited to)
 * thin provisioning (over-committing storage)
 * snapshot support
 * volume types with different storage allocation methods

Thin provisioning
Recent versions of LVM2 (2.02.89) support "thin" volumes. Thin volumes are to block devices what sparse files are to file systems. Thus, a thin logical volume within a pool can be "over-committed": its presented size can be larger than the allocated size - it can even be larger than the pool itself. Just like a sparse file, the extents are allocated as the block device gets populated. If the file system has discard support extents are freed again as files are removed, reducing space utilization of the pool.

Within LVM, such a thin pool is a special type of logical volume, which itself can host logical volumes.

Creating a thin pool
Each thin pool has metadata associated with it, which is added to the thin pool size. LVM will compute the size of the metadata based on the size of the thin pool as the minimum of pool_chunks * 64 bytes or 2MiB, whichever is larger. The administrator can select a different metadata size as well.

To create a thin pool, add the --type thin-pool --thinpool thin_pool parameters to :

The above example creates a thin pool called thin_pool with a total size of 150 MB. This is the real allocated size for the thin pool (and thus the total amount of actual storage that can be used).

To explicitly ask for a certain metadata size, use the --metadatasize parameter:

Due to the metadata that is added to the thin pool, the intuitive way of using all available size in a volume group for a logical volume does not work (see LVM bug |812726):

Note the thin pool does not have an associated device node like other LV's.

Creating a thin logical volume
A thin logical volume is a logical volume inside the thin pool (which itself is a logical volume). As thin logical volumes are sparse, a virtual size instead of a physical size is specified using the -V parameter:

In this example, the (thin) logical volume lvol1 is exposed as a 300MB-sized device, even though the underlying pool only holds 150MB of real allocated storage.

It is also possible to create both the thin pool as well as the logical volume inside the thin pool in one command:

Listing thin pools and thin logical volumes
Thin pools and thin logical volumes are special types of logical volumes, and as such as displayed through the  command. The  command will also detect these logical volumes.

Extending a thin pool
The thin pool is expanded like a non-thin logical volume using. For instance:

Extending a thin logical volume
A thin logical volume is expanded just like a regular one:

Note that the  command uses the -L option (or -l if extent counts are used) and not a "virtual size" option as was used during the creation.

Reducing a thin pool
Currently, LVM cannot reduce the size of the thin pool. See LVM bug |812731.

Reducing a thin logical volume
Thin logical volumes are reduced just like regular logical volumes.

For instance:

Note that the  command uses the -L option (or -l if extent counts are used) and not a "virtual size" option as was used during the creation.

Removing thin pools
Thin pools cannot be removed until all the thin logical volumes inside it are removed.

When a thin pool no longer services any thin logical volume, it can be removed through the  command:

LVM2 snapshots and thin snapshots
A snapshot is a logical volume that acts as copy of another logical volume. It displays the state of the original logical volume at the time of snapshot creation.

Creating a snapshot logical volume
A snapshot logical volume is created using the -s option to. Snapshot logical volumes are still given allocated storage as LVM "registers" all changes made to the original logical volume and stores these changes in the allocated storage for the snapshot. When querying the snapshot state, LVM will start from the original logical volume and then check all changes registered, "undoing" the changes before showing the result to the user.

A snapshot logical volume henceforth "growths" at the rate that changes are made on the original logical volume. When the allocated storage for the snapshot is completely used, then the snapshot will be removed automatically from the system.

The above example creates a snapshot logical volume called 20140412_lvol1, based on the logical volume lvol1 in volume group vg0. It uses 10% of the space (extents actually) allocated to the volume group.

Accessing a snapshot logical volume
Snapshot logical volumes can be mounted like regular logical volumes. They are even not restricted to read-only operations - it is possible to modify snapshots and thus use it for things such as testing changes before doing these on a "production" file system.

As long as snapshot logical volumes exist, the regular/original logical volume cannot be reduced in size or removed.

LVM thin snapshots
To create a thin snapshot, the  command is used with the   option. No size declaration needs to be passed on:

Thin logical volume snapshots have the same size as their original thin logical volume, and use a physical allocation of 0 just like all other thin logical volumes.

It is also possible to take snapshots of snapshots:

Thin snapshots have several advantages over regular snapshots. First, thin snapshots are independent of their original logical volume once created. The original logical volume can be shrunk or deleted without affecting the snapshot. Second, thin snapshots can be efficiently created recursively (snapshots of snapshots) without the "chaining" overhead of regular recursive LVM snapshots.

Rolling back to snapshot state
To rollback the logical volume to the version of the snapshot, use the following command:

This might take a couple of minutes, depending on the size of the volume.

Rolling back thin snapshots
For thin volumes,  does not work. Instead, delete the original logical volume and rename the snapshot:

Different storage allocation methods
LVM supports different allocation methods for storage:
 * linear volumes (which is the default)
 * mirrored volumes (in a more-or-less active/standby setup)
 * striping (RAID0)
 * mirrored volumes (RAID1 - which is more an active/active setup)
 * striping with parity (RAID4 and RAID5)
 * striping with double parity (RAID6)
 * striping and mirroring (RAID10)

Linear volumes
Linear volumes are the most common kind of LVM volumes. LVM will attempt to allocate the logical volume to be as physically contiguous as possible. If there is a physical volume large enough to hold the entire logical volume, then LVM will allocate it there, otherwise it will split it up into as few pieces as possible.

The commands introduced earlier on to create volume groups and logical volumes create linear volumes.

Because linear volumes have no special requirements, they are the easiest to manipulate and can be resized and relocated at will. If a logical volume is allocated across multiple physical volumes, and any of the physical volumes become unavailable, then that logical volume cannot be started anymore and will be unusable.

Mirrored volumes
LVM supports mirrored volumes, which provide fault tolerance in the event of drive failure. Unlike RAID1, there is no performance benefit - all reads and writes are delivered to a single side of the mirror.

To keep track of the mirror state, LVM requires a log to be kept. It is recommended (and often even mandatory) to position this log on a physical volume that does not contain any of the mirrored logical volumes. There are three kind of logs that can be used for mirrors:


 * 1) Disk is the default log type. All changes made are logged into extra metadata extents, which LVM manages. If a device fails, then the changes are kept in the log until the mirror can be restored again.
 * 2) Mirror logs are disk logs that are themselves mirrored.
 * 3) Core mirror logs record the state of the mirror in memory only. LVM will have to rebuild the mirror every time it is activated. This type is useful for temporary mirrors.

To create a logical volume with a single mirror, pass the -m 1 argument (to select standard mirroring) with optionally --mirrorlog to select a particular log type:

The -m 1 tells LVM to create one (additional) mirror, so requiring 2 physical volumes. The --nosync option is an optimization - without it LVM will try synchronize the mirror by copying empty sectors from one logical volume to another.

It is possible to create a mirror of an existing logical volume:

The -b option does the conversion in the background as this can take quite a while.

To remove a mirror, set the number of mirrors (back) to 0:

If part of the mirror is unavailable (usually because the disk containing the physical volume has failed), the volume group will need to be brought up in degraded mode:

On the first write, LVM will notice the mirror is broken. The default policy ("remove") is to automatically reduce/break the mirror according to the number of pieces available. A 3-way mirror with a missing physical volume will be reduced to 2-way mirror; a 2-way mirror will be reduced to a regular linear volume. If the failure is only transient, and the missing physical volume returns after LVM has broken the mirror, the mirrored logical volume will need to be recreated on it.

To recover the mirror, the failed physical volume needs to be removed from the volume group, and a replacement physical volume needs to be added (or if the volume group has a free physical volume, it can be created on that one). Then the mirror can be recreated with lvconvert at which point the old physical volume can be removed from the volume group:

It is possible to have LVM recreate the mirror with free extents on a different physical volume if one side fails. To accomplish that, set  to allocate in.

Thin mirrors
It is not (yet) possible to create a mirrored thin pool or thin volume. It is possible to create a mirrored thin pool my creating a normal mirrored logical volume and then converting the logical volume to a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Striping (RAID0)
Instead of a linear volume, where multiple contiguous physical volumes are appended, it possible to create a striped or RAID 0 volume for better performance. This will alternate storage allocations across the available physical volumes.

To create a striped volume over three physical volumes:

The -i option indicates over how many physical volumes the striping should be done.

It is possible to mirror a stripe set. The -i and -m options can be combined to create a striped mirror:

This creates a 2 physical volume stripe set and mirrors it on 2 different physical volumes, for a total of 4 physical volumes. An existing stripe set can be mirrored with lvconvert.

A thin pool can be striped like any other logical volume. All the thin volumes created from the pool inherit that settings - do not specify it manually when creating a thin volume.

It is not possible to stripe an existing volume, nor reshape the stripes across more/less physical volumes, nor to convert to a different RAID level/linear volume. A stripe set can be mirrored. It is possible to extend a stripe set across additional physical volumes, but they must be added in multiples of the original stripe set (which will effectively linearly append a new stripe set).

Mirroring (RAID1)
Unlike RAID 0, which is striping, RAID 1 is mirroring, but implemented differently than the original LVM mirror. Under RAID1, reads are spread out across physical volumes, improving performance. RAID1 mirror failures do not cause I/O to block because LVM does not need to break it on write.

Any place where an LVM mirror could be used, a RAID 1 mirror can be used in its place. It is possible to have LVM create RAID1 mirrors instead of regular mirrors implicitly by setting mirror_segtype_default to raid1 in.

To create a logical volume with a single mirror:

Note the difference for creating a mirror: There is no mirrorlog specified, because RAID1 logical volumes do not have an explicit mirror log - it built-in to the logical volume.

It is possible to convert an existing logical volume to RAID 1:

To remove a RAID 1 mirror, set the number of mirrors to 0:

If part of the RAID1 is unavailable (usually because the disk containing the physical volume has failed), the volume group will need to be brought up in degraded mode:

Unlike an LVM mirror, writing does NOT breaking the mirroring. If the failure is only transient, and the missing physical volume returns, LVM will resync the mirror by copying cover the out-of-date segments instead of the entire logical volume. If the failure is permanent, then the failed physical volume needs to be removed from the volume group, and a replacement physical volume needs to be added (or if the volume group has a free physical volume, it can be created on a different PV). The mirror can then be repaired with lvconvert, and the old physical volume can be removed from the volume group:

Thin RAID1
It is not (yet) possible to create a RAID 1 thin pool or thin volume. It is possible to create a RAID 1 thin pool by creating a normal mirrored logical volume and then converting the logical volume to a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will then merge them into a single logical volume.

Striping with parity (RAID4 and RAID5)
RAID 0 is not fault-tolerant - if any of the physical volumes fail then the logical volume is unusable. By adding a parity stripe to RAID 0 the logical volume can still function if a physical volume is missing. A new physical volume can then be added to restore fault tolerance.

Stripsets with parity come in 2 flavors: RAID 4 and RAID 5. Under RAID 4, all the parity stripes are stored on the same physical volume. This can become a bottleneck because all writes hit that physical volume, and it gets worse the more physical volumes are in the array. With RAID 5, the parity data is distributed evenly across the physical volumes so none of them become a bottleneck. For that reason, RAID 4 is rare and is considered obsolete/historical. In practice, all stripesets with parity are RAID 5.

Only the data physical volumes are specified with -i, LVM adds one to it automatically for the parity. So for a 3 physical volume RAID5, -i 2 is passed on and not -i 3.

When a physical volume fails, then the volume group will need to be brought up in degraded mode:

The volume will work normally at this point, however this degrades the array to RAID 0 until a replacement physical volume is added. Performance is unlikely to be affected while the array is degraded - although it does need to recompute its missing data via parity, it only requires simple XOR for the parity block with the remaining data. The overhead is negligible compared to the disk I/O.

To repair the RAID5:

It is possible to replace a still working physical volume in RAID5 as well:

The same restrictions of stripe sets apply to stripe sets with parity as well: it is not possible to enable striping with parity on an existing volume, nor reshape the stripes with parity across more/less physical volumes, nor to convert to a different RAID level/linear volume. A stripe set with parity can be mirrored. It is possible to extend a stripe set with parity across additional physical volumes, but they must be added in multiples of the original stripe set with parity (which will effectively linearly append a new stripe set with parity).

Thin RAID5 logical volumes
It is not (yet) possible to create stripe set with parity (RAID5) thin pools or thin logical volumes. It is possible to create a RAID5 thin pool by creating a normal RAID5 logical volume and then converting the logical volume into a thin pool with lvconvert</tt>. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Striping with double parity (RAID6)
RAID 6 is similar to RAID 5, however RAID 6 can survive up to two physical volume failures, thus offering more fault tolerance than RAID5 at the expense of extra physical volumes.

Like raid5, the -i option is used to specify the number of physical volumes to stripe, excluding the 2 physical volumes for parity. So for a 5 physical volume RAID6, pass on -i 3 and not -i 5.

Recovery for RAID6 is the same as RAID5.

Thin RAID6 logical volumes
It is not (yet) possible to create a RAID6 thin pool or thin volumes. It is possible to create a RAID6 thin pool by creating a normal RAID6 logical volume and then converting the logical volume into a thin pool with lvconvert</tt>. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

LVM RAID10
RAID10 is a combination of RAID0 and RAID1. It is more powerful than RAID0+RAID1 as the mirroring is done at the stripe level instead of the logical volume level, and therefore the layout doesn't need to be symmetric. A RAID10 volume can tolerate at least a single missing physical volume, and possibly more.

Both the -i and -m options are specified: -i is the number of stripes and -m is the number of mirrors. Two stripes and 1 mirror requires 4 physical volumes.

Thin RAID10
It is not (yet) possible to create a RAID10 thin pool or thin volumes. It is possible to create a RAID10 thin pool by creating a normal RAID10 logical volume and then converting the logical volume into a thin pool with. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Experimenting with LVM
It is possible to experiment with LVM without using real storage devices. To accomplish this, loopback devices are created.

First make sure to have the loopback module loaded.

Next configure LVM to not use udev to scan for devices:

Create some image files which will become the storage devices. The next example uses five files for a total of about ~10GB of real hard drive space:

Check which loopback devices are available:

Assuming all loopback devices are available, next create the devices:

The devices are now available to use as any other hard drive in the system (and thus be perfect for physical volumes).

Troubleshooting
LVM has a few features that already provide some level of redundancy. However, there are situations where it is possible to restore lost physical volumes or logical volumes.

vgcfgrestore utility
By default, on any change to a LVM physical volume, volume group, or logical volume, LVM2 create a backup file of the metadata in. These files can be used to recover from an accidental change (like deleting the wrong logical volume). LVM also keeps a backup copy of the most recent metadata in. These can be used to restore metadata to a replacement disk, or repair corrupted metadata.

To see what states of the volume group are available to be restored (partial output to improve readability):

Recovering an accidentally deleted logical volume
Assuming the logical volume lvm_raid1 was accidentally removed from volume group vg0, it is possible to recover it as follows:

Replacing a failed physical volume
It possible to do a true "replace" and recreate the metadata on the new physical volume to be the same as the old physical volume:

The important line here is the UUID "unknown device".

This recreates the physical volume metadata, but not the missing logical volume or volume group data on the physical volume.

This now reconstructs all the missing metadata on the physical volume, including the logical volume and volume group data. However it doesn't restore the data, so the mirror is out of sync.

This will resync the mirror. This works with RAID 4,5 and 6 as well.

Deactivating a logical volume
It is possible to deactivate a logical volume with the following command:

It is not possible to mount the logical volume anywhere before it gets reactivated:

External resources

 * LVM2 sourceware.org
 * LVM tldp.org
 * LVM2 Wiki redhat.com