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>