BtrFs » Historique » Version 2
Version 1 (Fabien Dupont, 09/05/2013 13:01) → Version 2/9 (Fabien Dupont, 09/05/2013 13:58)
h1. BtrFs
{{>toc}}
h2. Présentation
BtrFs (se prononce « Butter FS ») est un filesystem de type CoW (« Copy on Write »). C'est à dire que deux données identiques (même CRC32) ne sont écrites qu'une seule fois sur le filesystem jusqu'à ce qu'une des deux soit modifiées.
Exemple :
<pre>
$ cat toto > fichier1 # « toto » est écrit quelque part sur le disque dur
$ cat toto > fichier2 # fichier2 devient un pointeur vers fichier1
$ sed -ie 's/o/a/g' fichier2 # « tata » est écrit quelque part sur le disque dur
# et fichier2 n'est plus un pointeur vers fichier1
</pre>
De plus, BtrFs est différents des systèmes de fichiers « classiques » (ext2/3/4) car il offre les fonctionnalités suivantes :
* possibilité d'écrire le filesystem sur plusieurs disques : raid1, raid0, raid10 et depuis le kernel 3.9, raid5 ou raid6.
* sous-volumes : il n'y a pas de notion de partitions mais un répertoire peut devenir la racine d'un nouveau volume.
* snapshots : une image peut être créée et utilisée pour sauvegarder ou restaurer l'état d'un filesystem (ou d'un sous-volume) à un instant T.
h2. Création d'un filesystem BtrFs sous debian
Le paquet « btrfs-tools » offre les outils permettant la création et la gestion d'un filesystem BtrFs.
<pre>
# apt-get install btrfs-tools
</pre>
h3. Single
Les données et les métadonnées sont écrites sur un seul disque.
<pre>
# mkfs.btrfs -d single /dev/sdb
</pre>
h3. raid0
Les données sont « stripées » sur deux disques. Il faut donc un minimum de 2 disques.
<pre>
# mkfs.btrfs -d raid0 -m raid0 /dev/sdb /dev/sdc
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+
| sdb | | sdc |
+-----+ +-----+
| a | | b |
| c | | d |
| e | | f |
| g | | h |
+-----+ +-----+
</pre>
Pros :
* Performance accrue en lecture, un fichier est lue sur deux disques, débit doublé.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Sécurité des données faible, si un seul disque tombe en panne, l'ensemble des données est perdue.
h3. raid1
Les données sont « mirrorées » sur deux disques. Il faut donc un minimum de 2 disques.
<pre>
# mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+
| sdb | | sdc |
+-----+ +-----+
| a | | a |
| b | | b |
| c | | c |
| d | | d |
| e | | e |
| f | | f |
| g | | g |
| h | | h |
+-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, N-1 disques peuvent tomber en panne avant de perdre les données.
Cons :
* Pour N disques de taille T, on n'a que T octets à disposition.
h4. raid10
Les données sont « mirrorées » sur N/2 disques puis « stripées » entre les 2 N/2 disques. Il faut donc un minimum de 4 disques.
<pre>
# mkfs.btrfs -d raid10 -m raid10 /dev/sdb /dev/sdc /dev/sdd /dev/sde
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
<-------raid0------->
<-----raid1-----> <-----raid1----->
+-----+ +-----+ +-----+ +-----+
| sdb | | sdc | | sdd | | sde |
+-----+ +-----+ +-----+ +-----+
| a | | a | | b | | b |
| c | | c | | d | | d |
| e | | e | | f | | f |
| g | | g | | h | | h |
+-----+ +-----+ +-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, N-1 disques dans chaque morceau du raid0 peuvent tomber en panne avant de perdre les données.
* Performance accrue en lecture, un fichier est lue sur deux disques, débit doublé.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Pour N disques de taille T, on n'a que (NÃT)/2 octets à disposition.
h4. raid5 (kernel >= 3.9)
Les données sont « stripées » sur N-1 disques puis la parité d'un « stripe » est écrite sur le dernier disque. Il faut donc un minimum de 3 disques.
<pre>
# mkfs.btrfs -d raid5 -m raid5 /dev/sdb /dev/sdc /dev/sdd
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+ +-----+
| sdb | | sdc | | sdd |
+-----+ +-----+ +-----+
| a | | b | | p1 |
| p2 | | c | | d |
| e | | p3 | | f |
| g | | h | | p4 |
+-----+ +-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, 1 disque peut tomber en panne avant de perdre les données.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Pour N disques de taille T, on n'a que (N-1)ÃT octets à disposition.
h4. raid6 (kernel >= 3.9)
Les données sont « stripées » sur N-2 disques puis la parité d'un « stripe » est « mirrorée » sur 2 disques. Il faut donc un minimum de 4 disques.
<pre>
# mkfs.btrfs -d raid6 -m raid6 /dev/sdb /dev/sdc /dev/sdd
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+ +-----+ +-----+
| sdb | | sdc | | sdd | | sde |
+-----+ +-----+ +-----+ +-----+
| a | | b | | p1 | | p1 |
| p2 | | c | | d | | p2 |
| p3 | | p3 | | e | | f |
| g | | p4 | | p4 | | h |
+-----+ +-----+ +-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, 2 disques peut tomber en panne avant de perdre les données.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Pour N disques de taille T, on n'a que (N-2)ÃT octets à disposition.
h2. Administration d'un volume BtrFs
h3. Sous-volumes (subvolumes)
Un sous-volume n'est _pas_ équivalent à LVM. C'est une racine sous la racine.
Un sous-volume peut contenir une hierarchie de fichiers ou bien une image (« snapshot ») d'un autre sous-volume à un instant T.
Par exemple, dans un même volume, on peut avoir :
<pre>
+-+- root (sous volume par défaut)
| +-- /bin
| +-- /usr
| +-- ...
|
+-+- home
| +-- /home
|
+-+- snapshot_root1
| +-- /bin
| +-- /usr
| +-- ...
|
.
.
</pre>
h4. Création d'un sous-volume
Par exemple, pour créer un sous-volume /mnt/home dans le volume BtrFs monté dans /mnt :
<pre>
# btrfs subvolume create /mnt/home
</pre>
/!\ /mnt/home ne doit _pas_ exister. Il apparaîtra tel un répertoire, du point de vue de l'utilisateur mais ce n'en n'est pas un.
h4. Création d'un snapshot dans un sous-volume :
Par exemple, pour créer un snapshot de /mnt/home :
<pre>
# ls -l /mnt/home/fab
/mnt/home/fab:
total 0
# btrfs subvolume snapshot /mnt/home /mnt/snapshot_of_home
# touch /mnt/home/fab/toto
# ls -l /mnt/home/fab /mnt/snapshot_of_home/fab
/mnt/home/fab:
total 0
-rw-r--r-- 1 root root 0 May 9 13:49 toto
/mnt/snapshot_of_home/fab:
total 0
</pre>
On voit bien que le snapshot contient l'état de /mnt/home avant la création du fichier toto.
h4. Monter un sous-volume
Pour monter un sous-volume précédement créé :
<pre>
# btrfs subvolume list /mnt
ID 261 gen 37 top level 5 path home
ID 262 gen 41 top level 5 path snapshot_of_home
# mount /dev/sdb1 /home -o subvolume=home
# df -HTP | grep sdb1
/dev/sdb1 btrfs 8.0T 6.7G 8.0T 1% /home
/dev/sdb1 btrfs 8.0T 6.7G 8.0T 1% /mnt
# mkdir /home/fab
# chown fab:fab /home/fab
# ls -ld /mnt/home/fab /home/fab
drwxr-xr-x 1 fab fab 8 May 9 13:49 /mnt/home/fab
drwxr-xr-x 1 fab fab 8 May 9 13:49 /home/fab
</pre>
{{>toc}}
h2. Présentation
BtrFs (se prononce « Butter FS ») est un filesystem de type CoW (« Copy on Write »). C'est à dire que deux données identiques (même CRC32) ne sont écrites qu'une seule fois sur le filesystem jusqu'à ce qu'une des deux soit modifiées.
Exemple :
<pre>
$ cat toto > fichier1 # « toto » est écrit quelque part sur le disque dur
$ cat toto > fichier2 # fichier2 devient un pointeur vers fichier1
$ sed -ie 's/o/a/g' fichier2 # « tata » est écrit quelque part sur le disque dur
# et fichier2 n'est plus un pointeur vers fichier1
</pre>
De plus, BtrFs est différents des systèmes de fichiers « classiques » (ext2/3/4) car il offre les fonctionnalités suivantes :
* possibilité d'écrire le filesystem sur plusieurs disques : raid1, raid0, raid10 et depuis le kernel 3.9, raid5 ou raid6.
* sous-volumes : il n'y a pas de notion de partitions mais un répertoire peut devenir la racine d'un nouveau volume.
* snapshots : une image peut être créée et utilisée pour sauvegarder ou restaurer l'état d'un filesystem (ou d'un sous-volume) à un instant T.
h2. Création d'un filesystem BtrFs sous debian
Le paquet « btrfs-tools » offre les outils permettant la création et la gestion d'un filesystem BtrFs.
<pre>
# apt-get install btrfs-tools
</pre>
h3. Single
Les données et les métadonnées sont écrites sur un seul disque.
<pre>
# mkfs.btrfs -d single /dev/sdb
</pre>
h3. raid0
Les données sont « stripées » sur deux disques. Il faut donc un minimum de 2 disques.
<pre>
# mkfs.btrfs -d raid0 -m raid0 /dev/sdb /dev/sdc
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+
| sdb | | sdc |
+-----+ +-----+
| a | | b |
| c | | d |
| e | | f |
| g | | h |
+-----+ +-----+
</pre>
Pros :
* Performance accrue en lecture, un fichier est lue sur deux disques, débit doublé.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Sécurité des données faible, si un seul disque tombe en panne, l'ensemble des données est perdue.
h3. raid1
Les données sont « mirrorées » sur deux disques. Il faut donc un minimum de 2 disques.
<pre>
# mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+
| sdb | | sdc |
+-----+ +-----+
| a | | a |
| b | | b |
| c | | c |
| d | | d |
| e | | e |
| f | | f |
| g | | g |
| h | | h |
+-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, N-1 disques peuvent tomber en panne avant de perdre les données.
Cons :
* Pour N disques de taille T, on n'a que T octets à disposition.
h4. raid10
Les données sont « mirrorées » sur N/2 disques puis « stripées » entre les 2 N/2 disques. Il faut donc un minimum de 4 disques.
<pre>
# mkfs.btrfs -d raid10 -m raid10 /dev/sdb /dev/sdc /dev/sdd /dev/sde
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
<-------raid0------->
<-----raid1-----> <-----raid1----->
+-----+ +-----+ +-----+ +-----+
| sdb | | sdc | | sdd | | sde |
+-----+ +-----+ +-----+ +-----+
| a | | a | | b | | b |
| c | | c | | d | | d |
| e | | e | | f | | f |
| g | | g | | h | | h |
+-----+ +-----+ +-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, N-1 disques dans chaque morceau du raid0 peuvent tomber en panne avant de perdre les données.
* Performance accrue en lecture, un fichier est lue sur deux disques, débit doublé.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Pour N disques de taille T, on n'a que (NÃT)/2 octets à disposition.
h4. raid5 (kernel >= 3.9)
Les données sont « stripées » sur N-1 disques puis la parité d'un « stripe » est écrite sur le dernier disque. Il faut donc un minimum de 3 disques.
<pre>
# mkfs.btrfs -d raid5 -m raid5 /dev/sdb /dev/sdc /dev/sdd
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+ +-----+
| sdb | | sdc | | sdd |
+-----+ +-----+ +-----+
| a | | b | | p1 |
| p2 | | c | | d |
| e | | p3 | | f |
| g | | h | | p4 |
+-----+ +-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, 1 disque peut tomber en panne avant de perdre les données.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Pour N disques de taille T, on n'a que (N-1)ÃT octets à disposition.
h4. raid6 (kernel >= 3.9)
Les données sont « stripées » sur N-2 disques puis la parité d'un « stripe » est « mirrorée » sur 2 disques. Il faut donc un minimum de 4 disques.
<pre>
# mkfs.btrfs -d raid6 -m raid6 /dev/sdb /dev/sdc /dev/sdd
</pre>
Par exemple pour un fichier contenant « abcdefgh », on aura sur les disques :
<pre>
+-----+ +-----+ +-----+ +-----+
| sdb | | sdc | | sdd | | sde |
+-----+ +-----+ +-----+ +-----+
| a | | b | | p1 | | p1 |
| p2 | | c | | d | | p2 |
| p3 | | p3 | | e | | f |
| g | | p4 | | p4 | | h |
+-----+ +-----+ +-----+ +-----+
</pre>
Pros :
* Sécurité des données forte, 2 disques peut tomber en panne avant de perdre les données.
* Plusieurs disques sont vus en un seul volume.
Cons :
* Pour N disques de taille T, on n'a que (N-2)ÃT octets à disposition.
h2. Administration d'un volume BtrFs
h3. Sous-volumes (subvolumes)
Un sous-volume n'est _pas_ équivalent à LVM. C'est une racine sous la racine.
Un sous-volume peut contenir une hierarchie de fichiers ou bien une image (« snapshot ») d'un autre sous-volume à un instant T.
Par exemple, dans un même volume, on peut avoir :
<pre>
+-+- root (sous volume par défaut)
| +-- /bin
| +-- /usr
| +-- ...
|
+-+- home
| +-- /home
|
+-+- snapshot_root1
| +-- /bin
| +-- /usr
| +-- ...
|
.
.
</pre>
h4. Création d'un sous-volume
Par exemple, pour créer un sous-volume /mnt/home dans le volume BtrFs monté dans /mnt :
<pre>
# btrfs subvolume create /mnt/home
</pre>
/!\ /mnt/home ne doit _pas_ exister. Il apparaîtra tel un répertoire, du point de vue de l'utilisateur mais ce n'en n'est pas un.
h4. Création d'un snapshot dans un sous-volume :
Par exemple, pour créer un snapshot de /mnt/home :
<pre>
# ls -l /mnt/home/fab
/mnt/home/fab:
total 0
# btrfs subvolume snapshot /mnt/home /mnt/snapshot_of_home
# touch /mnt/home/fab/toto
# ls -l /mnt/home/fab /mnt/snapshot_of_home/fab
/mnt/home/fab:
total 0
-rw-r--r-- 1 root root 0 May 9 13:49 toto
/mnt/snapshot_of_home/fab:
total 0
</pre>
On voit bien que le snapshot contient l'état de /mnt/home avant la création du fichier toto.
h4. Monter un sous-volume
Pour monter un sous-volume précédement créé :
<pre>
# btrfs subvolume list /mnt
ID 261 gen 37 top level 5 path home
ID 262 gen 41 top level 5 path snapshot_of_home
# mount /dev/sdb1 /home -o subvolume=home
# df -HTP | grep sdb1
/dev/sdb1 btrfs 8.0T 6.7G 8.0T 1% /home
/dev/sdb1 btrfs 8.0T 6.7G 8.0T 1% /mnt
# mkdir /home/fab
# chown fab:fab /home/fab
# ls -ld /mnt/home/fab /home/fab
drwxr-xr-x 1 fab fab 8 May 9 13:49 /mnt/home/fab
drwxr-xr-x 1 fab fab 8 May 9 13:49 /home/fab
</pre>