BTRFS is a new-ish filesystem that is available to GNU/Linux systems, among them Ubuntu distributions and their derivatives. Pronounced in various ways (my favorite is “Better FS”), it has been under active development for at least the last five years, though the developers have granted it stable status only since 2013. It aims to replace the venerable ext* series of filesystems as the default choice for Linux systems, sometime in the short-to-medium term. This filesystem rose above the radar of many systems administrators even before it was claimed to be stable, since the brief was impressive. It has a features list that contains not only RAID 0 and 1 capacities - within the filesystem itself, not having to mess around with mdadm any more - but also subvolumes, snapshots and copy-on-write. In practice, this means that previously, GNU/Linux systems administrators who needed to administer large, complex file-systems while ensuring no data could ever be lost, either cobbled together various techniques to achieve what they needed, or looked towards more exotic offerings from large server vendors. Sun Microsystems’ ZFS is one such, and probably stands as one of the sources of inspiration for BTRFS. However, licensing concerns mean that ZFS may never get into the Linux kernel code base. Its use on Linux systems has been achieved only through the FUSE userland-based mechanism, which effectively curtails its use for a system’s root disk.

BTRFS est un système de fichiers assez nouveau, disponible pour les systèmes GNU/Linux, parmi lesquels les distributions Ubuntu et leurs dérivés. Prononcé de diverses manières (ma préférée est « Better FS »), il a été en développement actif pendant au moins les cinq dernières années, bien que les développeurs lui aient accordé un statut stable seulement depuis 2013. Il vise à remplacer la vénérable série des systèmes de fichiers ext* comme choix par défaut pour les systèmes Linux, à court ou à moyen terme.

Ce système de fichiers est apparu sur le radar de nombreux administrateurs système avant même d'être considéré comme stable, tellement il semblait impressionnant. Sa liste de fonctionnalités contient non seulement les capacités RAID 0 et 1 - au sein du système de fichiers, sans plus avoir à s'amuser avec mdadm -, mais aussi les sous-volumes, les « snapshot » et la copie sur écriture. Dans la pratique, cela signifie que, précédemment, les administrateurs de systèmes GNU/Linux qui avaient besoin d'administrer de grands systèmes de fichiers complexes tout en assurant qu'aucune donnée ne pourrait jamais se perdre, soit concoctaient différentes techniques pour réaliser ce dont ils avaient besoin, soit regardaient vers des offres plus exotiques de grands fournisseurs de serveurs. Le ZFS de Sun Microsystems en est une, et probablement est, en fait, l'une des sources d'inspiration pour BTRFS. Cependant, les problèmes de licence impliquaient que ZFS ne pourrait jamais entrer dans le code de base du noyau Linux. Son utilisation sur les systèmes Linux n'a été réussie qu'à travers le mécanisme basé sur FUSE en mode utilisateur, ce qui limite son utilisation efficace pour le disque racine d'un système.

However, BTRFS has not yet been much in view of the normal desktop user, perhaps because it has been seen as a bit of a guru’s plaything, as well as a tad complicated to figure out. In this piece I will try to convince you, the reader, of its use for, let us say, at the very least the “power users” (whatever that may mean). INSTALLATION Installing a system with a recent version of Ubuntu is a breeze, since they already have the appropriate drivers built into the kernel, and helper libraries and tools are available in the btrfs-tools package. I will be using Ubuntu 14.10 version compiled for i386, but any version of 14.10, 14.04 or Linux Mint 17 will work just as well. If using a distribution that lacks them, you may need to boot into the Live CD environment, connect to the Internet and install the required package.

Cependant, BTRFS n'a pas encore été beaucoup vu par l'utilisateur d'ordinateur normal, peut-être parce qu'il a été considéré un peu comme un jouet de gourou, ainsi qu'un peu compliqué à comprendre. Dans cet article, je vais essayer de vous convaincre, lecteur, de son utilisation pour, disons, au moins les « super-utilisateurs » (quoi que cela puisse signifier).   INSTALLATION

L'installation d'un système avec une version récente d'Ubuntu est un jeu d'enfant, car les pilotes appropriés sont déjà intégrés au noyau, et les bibliothèques et les outils auxiliaires sont disponibles dans le paquet btrfs-tools. Je vais utiliser la version Ubuntu 14.10 compilée pour i386, mais n'importe quelle version parmi les 14.10, 14.04 ou Linux Mint 17 fonctionnera tout aussi bien. Si vous utilisez une distribution qui ne les contient pas, vous devrez peut-être démarrer dans l'environnement Live CD, vous connecter à Internet et installer le paquet nécessaire.

Start up the Live CD, and in the “Installation type” screen choose “Something else”. This gets you into manual partition management. The approved way to install a Linux system on a BTRFS filesystem is create at least two partitions: • A first partition for /boot. This needed to be of the ext* family, so why not ext4. This partition needs to be at least 200-300 MBytes in size, though 512 MBytes was probably wise to leave some extra space if you will be upgrading your kernel at some point in the future. • A second partition for the root (/) and the rest of your system. For a simple install, there is no need to create a separate /home partition, but more on that later. When creating a new partition, simply choose “btrfs” instead of “ext4”. The other options work in the usual way. In this case, I will be creating a 15 GByte partition - though it will get resized up further on. A simple partition scheme would be as follows. Please note (regarding the image below) /dev/sda was the USB pendrive I was booting from, while /dev/sdb was the (external) hard drive I was installing the system on.

Démarrez le Live CD, et dans l'écran « Type d'installation », choisissez « Autre chose ». Cela vous amène dans la gestion manuelle des partitions. La façon correcte d'installer un système Linux sur un système de fichiers BTRFS est de créer au moins deux partitions : • Une première partition /boot. Elle doit être de la famille ext*, alors pourquoi pas ext4. Cette partition doit être d'au moins 200 ou 300 Mo, mais 512 Mo est probablement plus sage pour laisser un peu d'espace supplémentaire si vous voulez faire une mise à niveau de votre noyau dans l'avenir. • Une seconde partition pour la racine (/) et le reste de votre système. Pour une installation simple, il n'est pas nécessaire de créer une partition /home séparée, mais nous y reviendrons.

Lorsque vous créez une nouvelle partition, il suffit de choisir « btrfs » au lieu de « ext4 ». Les autres options fonctionnent de la manière habituelle. Dans ce cas, je vais créer une partition de 15 Go - qui sera redimensionnée à la hausse plus loin.

Un schéma de partition simple serait le suivant. S'il vous plaît remarquez (concernant l'image ci-dessous) que /dev/sda était la clé USB sur laquelle j'ai effectué le démarrage, alors que /dev/sdb était le disque dur (externe) sur lequel j'installais le système.

The need for the separate /boot partition was because, until recently, GRUB did not know about BTRFS partitions, and complained if the /boot directory has been placed on such a file system - although the system did actually boot correctly anyway. Just to make it cease nagging, people used to create this separate partition. In more recent versions of Ubuntu, this is no longer necessary, and a single root BTRFS partition is altogether sufficient. That’s it, the rest of the installation should go in the usual way. SUBVOLUMES Now, reboot your system and open a terminal. If you issue the “mount” or “df” commands, you should see something a little bit weird (shown top right). That’s right, beside the /dev/sda1 boot partition that seems to be correctly mounted, we see the root /dev/sda2 partition mounted not once, but twice! But, it we take a closer look at the output from “mount”, we can see it is indicating “subvol=@” on one mount, and “subvol=@home”.

La partition /boot doit séparée parce que, jusqu'à récemment, GRUB ne connaissait pas les partitions BTRFS et se plaignait si le répertoire /boot était placé sur un tel système de fichier - même si le système démarrait correctement de toute façon. Juste pour éviter qu'il se plaigne, les gens créaient cette partition séparée.

Dans les versions plus récentes d'Ubuntu, ce n'est plus nécessaire, et une seule partition racine BTRFS est tout à fait suffisante.

Ça y est, le reste de l'installation devrait se passer de la façon habituelle.

SOUS-VOLUMES

Maintenant, redémarrez votre système et ouvrez un terminal. Si vous saisissez les commandes « mount » ou « df », vous devriez voir quelque chose d'un peu bizarre (voir en haut à droite).

C'est vrai, à côté de la partition de démarrage /dev/sda1 qui semble être montée correctement, nous voyons la partition racine /dev/sda2 montée non pas une, mais deux fois ! Toutefois, en regardant de plus près la sortie de « mount », nous pouvons voir qu'il est indiqué « subvol=@ » sur un montage, et « subvol=@home ».

Subvolumes are one of the new features of BTRFS, compared to more traditional filesystems. With this system, different spaces can share available disk space within the BTRFS partition. However, subvolume contents are somehow separate, and can be mounted in different locations on our directory tree. OpenSUSE takes this principle a way further, creating subvolumes for many other directories. Naturally, we can create further subvolumes manually and set them up if needed. For example, in a server it would be usual practice to keep the contents of /var separate from the rest of the system. Let us create a subvolume for that. We will need to create it inside the parent partition /dev/sda2, and not the subvolume @. As root, let us mount /dev/sda2 on /mnt, and create the @var subvolume on it: $ sudo bash # mount /dev/sda2 /mnt # btrfs sub create /mnt/@var Create subvolume '/mnt/@var' # umount /dev/sda2

Les sous-volumes sont une des nouvelles fonctionnalités de BTRFS, par rapport aux systèmes de fichiers plus traditionnels. Avec ce système, les différents espaces peuvent partager l'espace disque disponible dans la partition BTRFS. Cependant, le contenu des sous-volumes sont en quelque sorte séparés, et peuvent être montés dans des endroits différents sur notre arborescence.

OpenSUSE va même plus loin dans ce principe, en créant des sous-volumes pour beaucoup d'autres répertoires. Naturellement, nous pouvons créer d'autres sous-volumes manuellement et les mettre en place, si nécessaire.

Par exemple, dans un serveur, une pratique habituelle est de maintenir le contenu de /var séparé du reste du système. Créons un sous-volume pour cela. Nous devons le créer à l'intérieur de la partition parent /dev/sda2, et pas dans le sous-volume @. En tant que root, nous montons /dev/sda2 dans /mnt, et créons le sous-volume @var dessus :

$ sudo bash # mount /dev/sda2 /mnt # btrfs sub create /mnt/@var Créer le sous-volume « /mnt/@var » # umount /dev/sda2

We can now list all available subvolumes: # btrfs sub list / ID 257 gen 208 top level 5 path @ ID 258 gen 208 top level 5 path @home ID 264 gen 207 top level 5 path @var We can mount the new subvolume temporarily on /mnt to move over the contents of /var: # mount -o subvol=@var /dev/sda2 /mnt # mv /var/* /mnt/ Now, unmount the subvolume from its temporary position on /mnt and mount it on /var: # umount /mnt # mount -o subvol=@var /dev/sda2 /var

Nous pouvons maintenant lister tous les sous-volumes disponibles :

# btrfs sub list / ID 257 gen 208 top level 5 path @ ID 258 gen 208 top level 5 path @home ID 264 gen 207 top level 5 path @var

Nous pouvons monter le nouveau sous-volume temporairement dans /mnt pour déplacer le contenu de /var :

# mount -o subvol=@var /dev/sda2 /mnt # mv /var/* /mnt/

Maintenant, démontez le sous-volume de sa position temporaire sur /mnt et montez-le sur /var:

# umount /mnt # mount -o subvol=@var /dev/sda2 /var

Let us check we have everything mounted correctly: # mount /dev/sda2 on / type btrfs (rw,subvol=@) /dev/sda2 on /home type btrfs (rw,subvol=@home) /dev/sda1 on /boot type ext4 (rw) /dev/sda2 on /var type btrfs (rw,subvol=@var) That looks good. Just to make sure this partition is also mounted on reboot, add it to /etc/fstab. For example: # echo “/dev/sda2 /var btrfs defaults,subvol=@var 0 3” » /etc/fstab (Please do make sure you use *two* » symbols - or you will end up overwriting the whole file!) Of course, it is even better to use volume UUIDs when editing the /etc/fstab. If your disc is on an external connector, what appears as /dev/sda on one system may very well become /dev/sdb or /dev/sdc on another, with more internal units installed - while UUIDs remain the same. A complete /etc/fstab with our current configuration could be that shown below.

Vérifions que nous avons tout monté correctement :

# mount /dev/sda2 on / type btrfs (rw,subvol=@) /dev/sda2 on /home type btrfs (rw,subvol=@home) /dev/sda1 on /boot type ext4 (rw) /dev/sda2 on /var type btrfs (rw,subvol=@var)

Cela semble bon. Juste pour être sûr que cette partition est également montée au redémarrage, ajoutez-la à /etc/fstab. Par exemple :

# echo “/dev/sda2 /var btrfs defaults,subvol=@var 0 3” » /etc/fstab

(S'il vous plaît, assurez-vous que vous utilisez *deux* symboles » - sinon vous allez écraser le fichier complet.)

Bien sûr, c'est encore mieux d'utiliser les UUID des volumes lorsque vous modifiez le fichier /etc/fstab. Si votre disque est sur un connecteur externe, ce qui apparaît comme /dev/sda sur un système peut très bien devenir /dev/sdb ou /dev/sdc sur un autre, avec plus d'unités internes installées - alors que les UUID restent les mêmes. Un fichier /etc/fstab complet avec notre configuration actuelle pourrait être celui représenté ci-dessous.

Note that the very same UUID is used for all three subvolumes of the BTRFS partition. They also have individual subvolume UUIDs, but these are less often used. It is important to note that the contents of subvolumes do share space within the same filesystem. Subvolumes may be a practical way of separating data structures, and they can also be used to make separate backups (of the system itself, and of user’s data). But if our partition gets nuked for whatever reason, all subvolumes go with it. This is why I still prefer different partitions, if at all possible on different physical disks, for the root / system and for the /home directory. ADDING PARTITIONS TO INCREASE AVAILABLE SPACE When we installed the system, we chose to create a rather small partition for use as our BTRFS root filesystem. A rather large amount of space is still unused, and available should we wish to increase our disk space.

Remarquez que le même UUID est utilisé pour les trois sous-volumes de la partition BTRFS. Ils ont aussi des UUID individuels de sous-volume, mais ceux-ci sont moins souvent utilisés.

Il est important de noter que le contenu des sous-volumes partage l'espace à intérieur d'un même système de fichiers. Les sous-volumes peuvent être un moyen pratique de séparer les structures de données, et ils peuvent également être utilisés pour faire des sauvegardes distinctes (du système lui-même, et des données de l'utilisateur). Mais si notre partition est atomisée pour une raison quelconque, tous les sous-volumes disparaissent avec elle. C'est pourquoi je préfère toujours des partitions différentes pour le système racine / et pour le répertoire /home, si possible sur des disques physiques différents.

Ajout de partitions pour augmenter l'espace disponible

Lorsque nous avons installé le système, nous avons choisi de créer une assez petite partition pour notre système de fichiers racine BTRFS. Une assez grande quantité d'espace est encore inutilisée et disponible pour augmenter notre espace disque, si nous voulons le faire.

Our root filesystem is mounted, and in fact our computer’s operating system is running from it. This is why gparted cannot resize it on the fly, and instead displays the key icon next to the partition name. However, we can use the free space to create a new partition, in this case /dev/sda3. We will not need to create it with a specific filesystem for our use, so it can be left just as a new, but unformatted partition. Now, we can add this new partition to /dev/sda2, to extend available space. This is as simple as adding the new partition to the existing device, and re-balancing data across partitions. Interestingly enough, adding the device is almost instantaneous, while balancing may take some time depending on partition sizes: # btrfs dev add /dev/sda3 / Performing full device TRIM (45.16GiB) … root@alan-crucial:~# btrfs bal start / Done, had to relocate 10 out of 10 chunks As a side note, it can be observed that the BTRFS subsystem has correctly recognized the physical disk as an SSD unit, and has accordingly activated TRIM.

Notre système de fichiers racine est monté, et le système d'exploitation de notre ordinateur est exécuté dessus. C'est pourquoi gparted ne peut pas le redimensionner à la volée et affiche une clé à côté du nom de la partition.

Cependant, nous pouvons utiliser l'espace libre pour créer une nouvelle partition, dans ce cas, /dev/sda3. Nous n'aurons pas besoin de la créer avec un système de fichiers spécifique pour notre usage, de sorte qu'on peut la laisser comme une nouvelle partition, non formatée.

Maintenant, nous pouvons ajouter cette nouvelle partition à /dev/sda2, pour étendre l'espace disponible. C'est aussi simple que d'ajouter la nouvelle partition au périphérique existant et de ré-équilibrer les données sur les partitions. Curieusement, l'ajout du dispositif est presque instantané, mais l'équilibrage peut prendre un certain temps en fonction de la taille des partitions :

# btrfs dev add /dev/sda3 / Performing full device TRIM (45.16GiB) … root@alan-crucial:~# btrfs bal start / Done, had to relocate 10 out of 10 chunks

Notons en passant que le sous-système BTRFS a correctement reconnu le disque physique comme une unité SSD et a donc activé TRIM.

When we investigate the BTRFS file system, we find available space has increased to take up both /dev/sda2 and /dev/sda3: # btrfs fil show Label: none uuid: cc619f9e-5e46-4e77-9051-8733670fed4d Total devices 2 FS bytes used 3.91GiB devid 1 size 13.97GiB used 1.03GiB path /dev/sda2 devid 2 size 45.16GiB used 5.03GiB path /dev/sda3 Btrfs v3.14.1 SETTING UP RAID Another useful feature of BTRFS is that both RAID 0 and RAID 1 are baked into the filesystem itself. RAID 0, or “striping”, means that data is written across more than one hard drive or partition. This is what has been applied in the section above. On the other hand, RAID 1 or “mirroring” allows the filesystem to hold multiple copies of both our files and file-system metadata.

Lorsque nous examinons le système de fichiers BTRFS, nous voyons que l'espace disponible a augmenté pour compter à la fois /dev/sda2 et /dev/sda3 :

# btrfs fil show Label: none uuid: cc619f9e-5e46-4e77-9051-8733670fed4d

  Total devices 2 FS bytes used 3.91GiB
  devid        1 size 13.97GiB used 1.03GiB path /dev/sda2
  devid        2 size 45.16GiB used 5.03GiB path /dev/sda3

Btrfs v3.14.1

Configuration RAID

Une autre caractéristique utile de BTRFS est que RAID 0 et RAID 1 sont tous les deux inclus dans le système de fichiers lui-même. RAID 0, ou « entrelacement », signifie que les données sont écrites sur plus d'un disque dur ou une partition. C'est ce qui a été appliqué dans la section ci-dessus.

En revanche, RAID 1, ou « miroir », permet au système de fichiers de contenir plusieurs copies à la fois de nos fichiers et des métadonnées du système de fichiers.

By default, BTRFS makes multiple (actually, just two) copies of only the metadata. This is the information referring to the actual placing of files on the disk sectors that used to be contained in a File Allocation Table (FAT) on some early file-systems. In modern systems, this information is spread all over the disk or partition, to reduce localized wear. Making two copies of metadata means the chance of getting corrupted file positions is reduced. Currently active options may be examined with the following command: # btrfs fil df / Data, single: total=4.00GiB, used=3.72GiB System, RAID1: total=32.00MiB, used=16.00KiB Metadata, RAID1: total=1.00GiB, used=192.17MiB Here, we see that System and Metadata elements are duplicated - with, by default, one copy on each device. User data (files) are held as only a single copy, however. This can be changed, by simply re-balancing the file-system with the appropriate options set: # btrfs bal start / -dconvert=raid1 Done, had to relocate 4 out of 6 chunks

Par défaut, BTRFS crée de multiples (en fait, seulement deux) exemplaires des seules métadonnées. C'est l'information concernant l'emplacement réel des fichiers sur les secteurs du disque qui était auparavant contenue dans une table d'allocation de fichiers (FAT) sur certains systèmes de fichiers. Dans les systèmes modernes, cette information est répartie sur tout le disque ou la partition, pour réduire l'usure localisée. Garder deux copies des métadonnées signifie que le risque d'avoir des fichiers corrompus est réduit. Les options actives peuvent être consultées avec la commande suivante :

# btrfs fil df / Data, single: total=4.00GiB, used=3.72GiB System, RAID1: total=32.00MiB, used=16.00KiB Metadata, RAID1: total=1.00GiB, used=192.17MiB

Ici, nous voyons que les éléments Système et Métadonnées sont dupliqués - avec, par défaut, une copie sur chaque périphérique. Les données de l'utilisateur (fichiers) sont détenues en un seul exemplaire, cependant. Ceci peut être changé, simplement en ré-équilibrant le système de fichiers avec l'ensemble d'options appropriées :

# btrfs bal start / -dconvert=raid1

Done, had to relocate 4 out of 6 chunks

If we check, we can see that both metadata (System, Metadata) and our files (Data) are now mirrored across the two units - even though they are of different sizes. # btrfs fil df / Data, RAID1: total=4.00GiB, used=3.72GiB System, RAID1: total=32.00MiB, used=16.00KiB Metadata, RAID1: total=1.00GiB, used=192.39MiB REMOVING PARTITIONS Adding new partitions and more space to our system is fine, but at times we need to remove partitions. Perhaps a physical disc has gone bad, or perhaps we wish to use one of the underlying partitions for some other purpose. In this test, we will remove /dev/sda2 from our BTRFS file system, leaving only /dev/sda1 used for /boot, formatted as ext4, and the 45 GiByte /dev/sda3 for our system and user data.

Si nous vérifions, nous pouvons voir qu'à la fois les métadonnées (System, Metadata) et nos fichiers (Data) sont maintenant en miroir entre les deux unités - même si elles sont de tailles différentes.

# btrfs fil df / Data, RAID1: total=4.00GiB, used=3.72GiB System, RAID1: total=32.00MiB, used=16.00KiB Metadata, RAID1: total=1.00GiB, used=192.39MiB

Supprimer des partitions

C'est bien d'ajouter de nouvelles partitions et plus d'espace sur notre système, mais parfois nous avons besoin de supprimer des partitions. Peut-être qu'un disque physique a été corrompu, ou peut-être que nous souhaitons utiliser l'une des partitions sous-jacentes à d'autres fins.

Dans ce test, nous allons supprimer /dev/sda2 de notre système de fichiers BTRFS, ne laissant que /dev/sda1 utilisé pour /boot, formaté en ext4, et les 45 GiO de /dev/sda3 pour nos données système et utilisateur.

Trying to simply remove /dev/sda2 does not work: # btrfs dev delete /dev/sda2 / ERROR: error removing the device '/dev/sda2' - unable to go below two devices on raid1 This is quite logical, as we will no longer be able to have 2 copies of each data block on different partitions when we reduce the partition count to just one. So, let us re-balance our system in order to use a single copy of each data block (-dconvert=single), and also to reduce the metadata copy count to one (-mconvert=single). This is not a risk-less situation, so if we were to perform this operation on a production system this would be a good time to make sure our backups are in order. This is why we will be required to append the -f parameter to force execution. So, re-balance the system and then remove /dev/sda2: # btrfs bal start -dconvert=single -mconvert=single -f / Done, had to relocate 6 out of 6 chunks # btrfs dev delete /dev/sda2 /

Essayer de retirer tout simplement /dev/sda2 ne fonctionne pas :

# btrfs dev delete /dev/sda2 / ERROR: error removing the device '/dev/sda2' - unable to go below two devices on raid1

C'est très logique, car nous ne pourrons plus avoir deux copies de chaque bloc de données sur des partitions différentes si nous réduisons le nombre de partitions à une seule. Alors, ré-équilibrons notre système afin d'utiliser un seul exemplaire de chaque bloc de données (-dconvert=single), et aussi pour réduire la copie des métadonnées à une (-mconvert=single). Ce n'est pas une situation sans risque, et si nous devions effectuer cette opération sur un système en production ce serait un bon moment pour s'assurer que nos sauvegardes ont été bien effectuées. C'est pourquoi nous devrons ajouter le paramètre -f pour forcer l'exécution.

Alors, re-équilibrez le système, puis retirez /dev/sda2 :

# btrfs bal start -dconvert=single -mconvert=single -f /

Done, had to relocate 6 out of 6 chunks # btrfs dev delete /dev/sda2 /

Let us check the filesystem status: # btrfs fil sho Label: none uuid: cc619f9e-5e46-4e77-9051-8733670fed4d Total devices 1 FS bytes used 3.92GiB devid 2 size 45.16GiB used 5.03GiB path /dev/sda3 We can now destroy /dev/sda2 if necessary: # dd if=/dev/zero of=/dev/sda2 bs=10M count=1 1+0 records in 1+0 records out 10485760 bytes (10 MB) copied, 0,720581 s, 14,6 MB/s The next time we reboot the system, /dev/sda2 will no longer be mounted. We should take care, if the /dev/sda names are given in /etc/fstab, to update this file before reboot. Otherwise, if the UUID nomenclature is used, this step will not be necessary. Then gparted or a similar tool can be used to remove the old partition and repartition if so desired:

Vérifions l'état du système de fichiers :

# btrfs fil sho Label: none uuid: cc619f9e-5e46-4e77-9051-8733670fed4d

  Total devices 1 FS bytes used 3.92GiB
  devid        2 size 45.16GiB used 5.03GiB path /dev/sda3

Nous pouvons maintenant détruire /dev/sda2 si nécessaire :

# dd if=/dev/zero of=/dev/sda2 bs=10M count=1 1+0 records in 1+0 records out 10485760 bytes (10 MB) copied, 0,720581 s, 14,6 MB/s

La prochaine fois que nous redémarrerons le système, /dev/sda2 ne sera plus montée. Nous devons prendre soin, si les noms /dev/sda sont cités dans /etc/fstab, de mettre à jour ce fichier avant le redémarrage. Sinon, si la nomenclature UUID est utilisée, cette étape n'est pas nécessaire.

Ensuite, gparted ou un outil similaire peut être utilisé pour enlever l'ancienne partition et la répartition si c'est ce qu'on souhaite :

USING SNAPSHOTS If you are like me, you will have, at some point in time, done Bad Things to your system, by way of testing extra programs, fiddling with system configuration, or, in general, learning the hard way how not to do things. In case of a really serious snafu, re-installing the system may be just about your only way out. OK, so it can take as little as 5 minutes on a modern machine - but not all of us use a modern machine and specially not for testing purposes, right? Wouldn’t it be nice if we had a safe-net at our disposal, that let us just roll back any changes to the system disk? Going back to a known point would simply be a question of rebooting the machine, and voilà! This is just one of the capabilities of the BTRFS snapshot mechanism. In essence, a snapshot is a means of taking an image of a volume. This snapshot will, in essence, remain unaltered, while we do our meddling with the live volume. BTRFS’s implementation of this feature is actually quite efficient, since only differential information is recorded about changes to files that have taken place since the snapshot was taken. Reverting to the snapshot simply consists of rolling back these changes, leaving the file system in its original state.

Utiliser les snapshots

Si vous êtes comme moi, vous avez, à un moment donné, fait de mauvaises choses à votre système, en testant des logiciels, en jouant avec la configuration du système, ou, en général, en apprenant sur le tas comment ne pas faire certaines choses. En cas de pépin vraiment sérieux, réinstaller le système peut être à peu près votre seul moyen d'en sortir. D'accord, cela peut ne prendre que 5 minutes sur une machine moderne - mais nous n'utilisons pas tous une machine moderne et surtout pas à des fins de test, n'est-ce pas ?

Ne serait-ce pas super si nous avions un filet de sécurité qui nous permettrait de revenir sur des modifications faite au disque système ? Retourner à un état qui fonctionnait serait tout simplement une question de redémarrage de la machine, et voilà !

C'est justement l'une des capacités du mécanisme d'instantané (« snapshot ») de BTRFS. En substance, un instantané est un moyen de prendre la photo d'un volume. Cet instantané restera par définition inchangé, pendant que nous modifierons le volume qui fonctionne. L'implémentation BTRFS de cette fonctionnalité est en fait très efficace, car seule l'information différentielle est enregistrée sur les modifications apportées aux fichiers depuis que le cliché a été pris. Revenir à l'instantané consiste simplement à refaire ces changements à l'envers, ramenant le système de fichiers dans son état original.

Just one point needs to be made before starting testing: snapshots may be made only of subvolumes. This is a further reason why forward planning of system subvolumes is important. Let us start with a simple example. Suppose we wish to make a snapshot of the /home subvolume. Let us call it home_snap. Start by mounting the parent partition on /mnt: # mount /dev/sda2 /mnt # btrfs sub snapshot /home /mnt/@home-snap Create a snapshot of '/home' in '/mnt/@home-snap' That’s it. If we consult the number of subvolumes in the BTRFS system, we can see both the mounted system, /home, and the new snapshot: # btrfs sub list / ID 257 gen 878 top level 5 path @ ID 258 gen 878 top level 5 path @home ID 264 gen 851 top level 5 path @var ID 279 gen 873 top level 5 path @home-snap

Il y a une chose à souligner avant de commencer les tests : les instantanés peuvent être faits uniquement sur les sous-volumes. C'est une autre raison pour laquelle il est important de planifier à l'avance des sous-volumes du système.

Commençons par un exemple simple. Supposons que nous voulions faire un instantané du sous-volume /home. Appelons-le home_snap. Commencez par monter la partition parent sur /mnt :

# mount /dev/sda2 /mnt # btrfs sub snapshot /home /mnt/@home-snap Create a snapshot of '/home' in '/mnt/@home-snap'

C'est tout. Si nous consultons le nombre de sous-volumes dans le système BTRFS, nous pouvons voir à la fois le système monté, /home, et le nouveau cliché :

# btrfs sub list / ID 257 gen 878 top level 5 path @ ID 258 gen 878 top level 5 path @home ID 264 gen 851 top level 5 path @var ID 279 gen 873 top level 5 path @home-snap

Now, let us do something really stupid, such as: # rm -r /home/alan/* # ls /home/alan So it’s time to roll back our snapshot. Since a snapshot can be seen as just another subvolume, perhaps the easiest way to do so is simply by modifying the corresponding entry in /etc/fstab (as shown below). Now, reboot the system and the original /home directory should come up correctly: # mount /dev/sda3 on / type btrfs (rw,subvol=@) /dev/sda3 on /home type btrfs (rw,subvol=@home-snap) /dev/sda3 on /var type btrfs (rw,subvol=@var) /dev/sda1 on /boot type ext4 (rw) The very same technique can be used with any snapshot on your system. So if you wish to roll back modifications to the system configuration or installed programs, subvolumes @ and @var are the ones to snapshot. Just remember to create new snapshots *before* making the alterations! Snapshots cost very little space…

Maintenant, faisons quelque chose de vraiment stupide, comme :

# rm -r /home/alan/* # ls /home/alan

Maintenant il est temps de revenir à notre snapshot. Puisqu'un snapshot peut être considéré simplement comme un autre sous-volume, peut-être que la façon la plus simple de le faire est de modifier l'entrée correspondante dans /etc/fstab (comme illustré ci-dessous).

Maintenant, redémarrez le système et le répertoire d'origine /home devrait être correct :

# mount /dev/sda3 on / type btrfs (rw,subvol=@) /dev/sda3 on /home type btrfs (rw,subvol=@home-snap) /dev/sda3 on /var type btrfs (rw,subvol=@var) /dev/sda1 on /boot type ext4 (rw)

La même technique peut être utilisée avec n'importe quel instantané sur votre système. Donc, si vous voulez revenir en arrière après des modifications de la configuration du système ou des programmes installés, il faut faire un snapshot des sous-volumes @ et @var. N'oubliez pas de créer de nouveaux instantanés *avant* de réaliser les modifications ! Les instantanés coûtent très peu d'espace…

SOME FINAL WORDS Everything we have done so far could just as well have been performed with other file systems. Perhaps the most impressive is that many tasks have been done without rebooting the system and on “live” (mounted) partitions. This is what really makes BTRFS magic for server administrators, since system downtime is a bad thing. But it may also help us mere mortals in a tricky situation. A second point that needs to be made is that, with these techniques, you can very easily mess up your system - I certainly did. So please be careful, and start out by playing with a computer and hard drive of which you don’t care very much about the contents. Finally, some tools are starting to become available to manage snapshots in the Ubuntu repositories – snapper and apt-btrfs-snapshot both may be worth some investigation… I may report on them later on in these columns, so stay tuned.

Quelques mots pour conclure

Tout ce que nous avons fait jusqu'à présent aurait tout aussi bien pu être réalisé avec d'autres systèmes de fichiers. Peut-être que le plus impressionnant est que de nombreuses tâches ont été effectuées sans avoir à redémarrer le système et sur des partitions en cours d'utilisation (montées). C'est ce qui rend BTRFS vraiment magique pour les administrateurs de serveurs, car les temps d'arrêt du système sont à éviter. Mais il peut aussi nous aider, nous simples mortels, dans une situation délicate.

Un deuxième point qui doit être noté est que, avec ces techniques, vous pouvez très facilement endommager votre système - ça m'est arrivé. Alors soyez prudents, et commencez par jouer avec un ordinateur et un disque dur dont le contenu vous importe peu.

Enfin, certains outils commencent à devenir disponibles dans les dépôts Ubuntu pour gérer les snapshots - snapper et apt-btrfs-snapshot méritent sans doute d'être essayés… J'en ferai peut-être un compte rendu ultérieurement dans ces colonnes, alors restez à l'écoute.