Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**Like most users, I do change my main working computer from time to time. When doing so, it may be a good time to start out afresh and give some thought to our hard disk setup. Even if cloud storage is widely used, limits on amounts of storage available (or its monthly fee), and network bandwidth to get our files up into the cloud, mean most users actually keep a sizable portion of their files on their local drives. Security considerations may also be a factor to consider, even with smaller files. In this article, I would like to set out several ideas that a more or less technical user could consider, strategies that may be of help both for data deduplication on your local drive, or for extending a drive with a limited capacity we are growing out of. 

Why mirror data?

Making multiple copies of all files that are written to our computer’s hard drives is a technique used in all server environments; every time a file is modified, alterations are written to more than one disk using one of several different schemes. The thinking being that, should one of these drives stop working suddenly: the second copy would not only ensure no data is lost, but, moreover, that service could continue immediately with no interruptions. Even when making a more pedestrian use of our personal computers, at some point we need to recognise that hard drives can, and do, fail.**

Comme la plupart des utilisateurs, je change de temps en temps mon ordinateur de travail principal. Ce faisant, c'est peut-être le moment de repartir de zéro et de réfléchir à la configuration du disque dur. Même si le stockage en nuage est largement utilisé, les limites en quantité de stockage disponible (ou son coût mensuel) et la bande passante du réseau pour acheminer nos fichiers vers le nuage signifient que la plupart des utilisateurs conservent en fait une part importante de leurs fichiers sur leurs disques locaux. Les considérations de sécurité peuvent également être un facteur à prendre en compte, même avec des fichiers plus petits. Dans cet article, j'aimerais exposer plusieurs idées qu'un utilisateur plus ou moins technique peut envisager, des stratégies qui peuvent être utiles à la fois pour la déduplication des données sur votre disque local, ou pour l'extension d'un disque dont nous atteignons la limite de capacité. 

Pourquoi mettre les données en miroir ?

Faire plusieurs copies de tous les fichiers qui sont écrits sur les disques durs de notre ordinateur est une technique utilisée dans tous les environnements de serveur ; chaque fois qu'un fichier est modifié, des copies sont écrites sur plus d'un disque en utilisant l'un des différents schémas. L'idée est que, si l'un de ces disques devait soudainement cesser de fonctionner, la deuxième copie permettrait non seulement de ne pas perdre de données, mais aussi de poursuivre immédiatement le service sans interruption. Même en faisant un usage plus posé de nos ordinateurs personnels, nous devons à un moment ou à un autre reconnaître que les disques durs peuvent tomber en panne et le font.


**Perhaps things are not as critical with modern SSD technology as they were at one point with rotational drives and their moving disks. The Mean Time Between Failures (MTBF) is a commonly-used metric that seems to have gone up with the switch to solid-state technology. But still, common sense tells us it is perhaps best not to entrust all our data to a single copy on our internal drive without making any backups. Fine… but there still are obstacles. In practice, not all backups are made on a schedule and kept up-to-date. At times, large files may never even get backed up at all -- neither to the cloud because they are too large, nor to a local external drive because we would need to think of plugging it in and performing the backup. Since, in the immortal words of Murphy’s Law, anything that can go wrong will do so and at the worst possible time, it can make sense to have multiple copies of all our data, made automatically, on our daily driver computer.

Clearly, making several copies of our files on a single disk would not be very useful at all. In the event of that disk having a catastrophic physical failure, we would lose access to all data it contained and the fact that it held several copies of each file would be moot. So, our goal must include the use of more than one physical hard drive on our computer. And, since messing around with the hard drives on our daily driver is probably not a great idea, what better time to take a look at the possibilities than when acquiring a new (or new-to-us) machine?**

Avec la technologie SSD moderne, les choses ne sont peut-être pas aussi critiques qu'elles l'étaient à un moment donné avec les disques rotatifs et leurs plateaux mobiles. Le temps moyen entre défaillances (MTBF - Mean Time Between Failures) est une mesure couramment utilisée qui semble avoir augmenté avec le passage à la technologie à semi-conducteurs. Mais malgré tout, le bon sens nous dit qu'il est peut-être préférable de ne pas confier toutes nos données à une seule copie sur notre disque interne, sans faire de sauvegardes. Bien... mais il y a encore des obstacles. Dans la pratique, toutes les sauvegardes ne sont pas effectuées selon un calendrier précis et ne sont pas tenues à jour. Il arrive même que des fichiers volumineux ne soient jamais sauvegardés - ni sur le cloud parce qu'ils sont trop volumineux, ni sur un disque externe local parce qu'il faudrait penser à le brancher et à effectuer la sauvegarde. Puisque, selon les mots immortels de la loi de Murphy, tout ce qui peut mal tourner le fera, et au pire moment possible, il peut être judicieux d'avoir plusieurs copies de toutes nos données, effectuées automatiquement, sur notre ordinateur de tous les jours.

Il est clair que faire plusieurs copies de nos fichiers sur un seul disque ne serait pas du tout utile. En cas de défaillance physique catastrophique de ce disque, nous perdrions l'accès à toutes les données qu'il contient et le fait qu'il contienne plusieurs copies de chaque fichier serait sans intérêt. Notre objectif doit donc d'inclure l'utilisation de plus d'un disque dur physique sur notre ordinateur. Et, puisque jouer avec les disques durs de notre ordinateur quotidien n'est probablement pas une bonne idée, quel meilleur moment pour examiner les possibilités que lors de l'acquisition d'une machine neuve (ou nouvelle pour nous) ?


**Why just mirror data?

The term “mirrored drive” implies the use of exactly two drives of a certain capacity. All data is written to disk in two copies, one on each disk. So, in essence, we are buying (and probably paying for) twice the disk space, and then using only the capacity of a single unit giving us a disk use efficiency of a mere 50%. 

In server rooms, this would be considered wasteful, since techniques such as RAID-5, RAID-6 or others allow higher efficiencies -- given a sufficient number of disks. For instance, with an 8-disk setup and using single parity, a RAID-5 would give us a useful space of 7 times the capacity of a single disk, while buying eight times that worth of space. 7/8 or 87,5% disk usage efficiency, while retaining the ability to survive the death of any single disk without losing any data is not a bad result. However, the immediate objection is that while it may be practical to house a large number of disks in a server rack, things are a lot more complicated in a typical laptop, or even some desktop computers with slim form factors. Even the smaller grade of commercially-available Network Attached Storage (NAS) units tend to have receptacles or bays for only two hard drives, thus limiting us to mirroring or – in technical parlance -- RAID-1.**

Pourquoi se contenter d'une mise en miroir des données ?

Le terme « disque miroir » implique l'utilisation de deux disques avec exactement la même capacité. Toutes les données sont écrites sur le disque en deux copies, une sur chaque disque. Donc, en substance, nous achetons (et payons probablement) deux fois l'espace disque, puis nous n'utilisons que la capacité d'une seule unité, ce qui nous donne une efficacité d'utilisation du disque d'à peine 50 %. 

Dans les salles de serveurs, cela serait considéré comme un gaspillage, puisque des techniques telles que RAID-5, RAID-6 ou autres permettent des efficacités plus élevées, à condition d'avoir un nombre suffisant de disques. Par exemple, avec une configuration de 8 disques et en utilisant une parité unique, un RAID-5 nous donnerait un espace utile de 7 fois la capacité d'un seul disque, tout en achetant huit fois cette valeur d'espace. 7/8 ou 87,5% d'efficacité d'utilisation du disque, tout en conservant la capacité de survivre à la mort d'un seul disque sans perdre aucune donnée n'est pas un mauvais résultat. Cependant, l'objection immédiate est que, s'il peut être pratique de loger un grand nombre de disques dans un rack de serveur, les choses sont beaucoup plus compliquées dans un ordinateur portable typique, ou même dans certains ordinateurs de bureau dans des formats étroits. Même les plus petites unités de NAS (Network Attached Storage - Stockage sur le réseau) disponibles dans le commerce ont tendance à avoir des réceptacles ou des baies pour deux disques durs seulement, ce qui nous limite à la mise en miroir ou, en langage technique, au RAID-1.


**On most desktop machines, the motherboard will have at least two SATA interfaces, where two rotational drives or two SSD drives with SATA interfaces may be plugged in. Even on many laptops, a second SATA hard drive may often be installed. If the laptop comes with an optical drive, a possibility would be to replace this little-used piece of equipment with a hard drive carrier that just plugs in the same space the DVD used to take. This is actually quite useful, mainly with laptops with the larger form factors.

Modern technology can also give us the possibility of using M2 interface SSD drives. These take up quite a bit less space than rotational drives with the SATA interface. Many laptop motherboards either come equipped with a disk drive with this interface, or an available M2 slot on the motherboard. However, most laptops will only have a single M2 interface, so some creativity may be necessary to combine, for instance, one SSD on the M2 interface with a second one on a SATA interface. This setup would not be advisable from the standpoint of speed, but should be doable if data redundancy is the primary objective and maximizing throughput is not (an SSD drive should be plenty fast, even on a SATA interface).**

Sur la plupart des ordinateurs de bureau, la carte mère dispose d'au moins deux interfaces SATA, sur lesquelles il est possible de brancher deux disques rotatifs ou deux disques SSD avec des interfaces SATA. Et même, sur de nombreux ordinateurs portables, un deuxième disque dur SATA peut souvent être installé. Si l'ordinateur portable est équipé d'un lecteur optique, il est possible de remplacer cette pièce peu utilisée par un support de disque dur qui s'insère simplement dans l'espace que prenait le DVD. Cette solution est en fait très utile, surtout pour les ordinateurs portables de grande taille.

La technologie moderne nous offre également la possibilité d'utiliser des disques SSD à interface M2. Ceux-ci prennent un peu moins de place que les disques rotatifs avec l'interface SATA. De nombreuses cartes mères d'ordinateurs portables sont équipées soit d'un lecteur de disque avec cette interface, soit d'un emplacement M2 disponible sur la carte mère. Cependant, la plupart des ordinateurs portables ne disposent que d'une seule interface M2, ce qui nécessite un peu de créativité pour combiner, par exemple, un SSD sur l'interface M2 avec un second sur une interface SATA. Cette configuration n'est pas recommandée du point de vue de la vitesse, mais devrait être réalisable si la redondance des données est l'objectif principal et que la maximisation du débit ne l'est pas (un disque SSD devrait être suffisamment rapide, même sur une interface SATA).


**On the other hand, desktop machines can use a PCI-Express adapter (extension card) to add an M2 interface to an existing machine. Some adapters are for a single M2 drive, while others even have space for two M2 interfaces thus allowing the user to build a two-drive system on a single adapter. What is more, the cost can be quite moderate, with some dual M2 interface adapters available for as little as 17 USD. However, maybe ensure your computer can boot off this extension card before acquiring one.

As a final thought, it may be useful to remember that using two partitions situated on the same physical disk would not be a good idea: not only will access times be lengthened since all data needs to be written twice to the very same disk thus creating a bottleneck, but if that unit goes out physically, both partitions will be lost at once thus rendering mirroring completely useless as implemented. To sum up: mirroring requires the use of (at least) two physical disks or drives.**

En revanche, les machines de bureau peuvent utiliser un adaptateur PCI-Express (carte d'extension) pour ajouter une interface M2 à une machine existante. Certains adaptateurs sont prévus pour un seul lecteur M2, tandis que d'autres ont même de l'espace pour deux interfaces M2, permettant ainsi à l'utilisateur de construire un système à deux lecteurs sur un seul adaptateur. De plus, le coût peut être très modéré, certains adaptateurs à double interface M2 étant disponibles pour seulement 17 $ US. Cependant, assurez-vous peut-être que votre ordinateur peut démarrer sur cette carte d'extension avant d'en acquérir une.

Pour finir, il peut être utile de rappeler que l'utilisation de deux partitions situées sur le même disque physique n'est pas une bonne idée : non seulement les temps d'accès seront allongés puisque toutes les données doivent être écrites deux fois sur le même disque, créant ainsi un goulot d'étranglement, mais si cette unité tombe physiquement en panne, les deux partitions seront perdues d'un coup, rendant ainsi la mise en miroir complètement inutile. En résumé, la mise en miroir nécessite l'utilisation de deux disques ou lecteurs physiques (au moins).


**Why extend an existing disk (striping) instead of mirroring?

For some people, mirroring data may not even be necessary for the user’s workflow. This would be the case when the user actually generates most data in the cloud – or on a company server, and the local hard drive is seen more as an archive to have a local copy of files in case the remote server is no longer available or some space needs to be freed up. Another scenario would be the “perfect” user who has one copy of each file locally, one copy on a remote server, and a third on cold storage, for instance on an archived external disk or optical media. Finally, we may at some times need a large amount of disk space to store files for a relatively short period of time, after which this large amount of data will be discarded. This is usually the scenario found while editing video, for instance, where the final product would certainly be kept, but perhaps not most of the original material if it is no longer relevant.

In these cases, would it not make more sense to use several drives to extend the total amount of space available, while retaining just a single copy of each file. In essence, we are trading some data security for available space. In the same way, the concept of mirroring deals with combining several hard drives into a single unit in which files are stored in two copies, striping is the analogous concept of combining several drives into one unit with a larger capacity but without duplication. In technical terms, where mirroring is often spoken of as RAID-1, striping is often known as RAID-0. In very large setups, these two techniques may be combined to create RAID-10 disk arrays, but this would probably be pertinent only on larger desktop computers with many hard drive bays.**

Pourquoi étendre un disque existant (striping) au lieu de le mettre en miroir ?

Pour certaines personnes, la mise en miroir des données peut même ne pas être nécessaire pour le flux de travail de l'utilisateur. Ce serait le cas lorsque l'utilisateur génère en fait la plupart de ses données dans le nuage - ou sur un serveur d'entreprise - et que le disque dur local est plutôt considéré comme une archive permettant de disposer d'une copie locale des fichiers au cas où le serveur distant ne serait plus disponible ou si de l'espace devait être libéré. Un autre scénario serait celui de l'utilisateur « parfait » qui a une copie de chaque fichier localement, une copie sur un serveur distant et une troisième sur un stockage à froid, par exemple sur un disque externe archivé ou un support optique. Enfin, nous pouvons parfois avoir besoin d'une grande quantité d'espace disque pour stocker des fichiers pendant une période relativement courte, après quoi cette grande quantité de données sera éliminée. C'est généralement le scénario que l'on rencontre lors du montage d'une vidéo, par exemple, où le produit final sera certainement conservé, mais peut-être pas la majeure partie du matériel original s'il n'est plus pertinent.

Dans ces cas, ne serait-il pas plus judicieux d'utiliser plusieurs disques pour augmenter la quantité totale d'espace disponible, tout en ne conservant qu'une seule copie de chaque fichier ? En fait, nous échangeons une certaine sécurité des données contre de l'espace disponible. De la même manière que le concept de mise en miroir consiste à combiner plusieurs disques durs en une seule unité dans laquelle les fichiers sont stockés en deux copies, le striping est le concept analogue qui consiste à combiner plusieurs disques en une unité de plus grande capacité mais sans duplication. En termes techniques, là où le mirroring est souvent appelé RAID-1, le striping est souvent connu sous le nom de RAID-0. Dans les très grandes configurations, ces deux techniques peuvent être combinées pour créer des matrices de disques RAID-10, mais cela ne serait probablement pertinent que sur les gros ordinateurs de bureau dotés de nombreuses baies pour disques durs.


**With some of the technologies used, striping may allow an existing disk drive to be extended – in some cases, even while it is mounted and working -- using a second drive.

What about the file system?

To my knowledge, there are at least four different ways of setting up either mirroring or striping on a personal computer. The first includes the use of dedicated physical hardware (thus, logically called “hardware RAID”) to which the two disks are plugged in, and which manages the complete set and presents it as a single unit to the user. However, issues include difficulties in using such a system on a laptop, the fact that not all desktop motherboards include this feature, and the hassle of using proprietary software (that often is not available under Linux) to recuperate data in the event of a problem. Needless to say, I would not advise using this way of going about it in a domestic or small business setting. It should also be noted that such setups may or may not allow “hot-plugging” new drives and associating the new disks to existing arrays. Some reading may be necessary if looking into using such a system.**

Avec certaines des technologies utilisées, le striping peut permettre d'étendre un disque existant - dans certains cas, même s'il est monté et en fonctionnement - en utilisant un deuxième disque.

Qu'en est-il du système de fichiers ?

À ma connaissance, il existe au moins quatre façons différentes de configurer le mirroring ou le striping sur un ordinateur personnel. La première consiste à utiliser un matériel physique dédié (appelé logiquement « RAID matériel ») sur lequel les deux disques sont branchés, qui gère l'ensemble et le présente à l'utilisateur comme une seule unité. Cependant, les problèmes incluent les difficultés d'utilisation d'un tel système sur un ordinateur portable, le fait que toutes les cartes mères d'ordinateurs de bureau n'intègrent pas cette fonctionnalité, et les tracas liés à l'utilisation de logiciels propriétaires (qui ne sont souvent pas disponibles sous Linux) pour récupérer les données en cas de problème. Inutile de dire que je ne conseillerais pas d'utiliser cette façon de faire dans un cadre domestique ou une petite entreprise. Il faut également noter que de telles configurations peuvent ou non permettre de « brancher à chaud » de nouveaux disques et d'associer les nouveaux disques aux matrices existantes. Un peu de lecture peut être nécessaire si vous envisagez d'utiliser un tel système.


**The second way would be to set up a RAID array using the Linux kernel’s built-in md (multiple-disk) subsystem. Utilities such as mdadm give us access to the system, which is quite mature and works well. But the interface and commands are not always user-friendly, which is a bit of a pity and also why I will not get further into this system. Interested users’ are referred to Jan Mussche’s “Install Mint On A Two Disk Raid 0 Set” in FullCircle issue number 104 -- switch from using RAID 0 (striping) to RAID 1 (mirroring) and the basics are about the same. In this case, “hot-plugging” new drives will be possible if your computer’s hardware allows it, which is in general not the case for consumer-grade computers and their drives. Adding new drives to existing arrays is possible in software, but will require some familiarity with the commands.

Mirroring or striping with BTRFS

This leaves us with two systems that are not based on managing individual disk drives, but whole file systems. In FCM#94, I wrote about the B-tree File System (BTRFS) and some of its applications. This file system has evolved even further since then, to the point that I consider it mature and use it on all my own computers (yes, I do eat my own dog food!). More to the point, Ubuntu’s installer, and that of most other modern Linux distributions, supports installing our system on a btrfs volume out of the box. GRUB can also use btrfs volumes, so very little fiddling is needed to set up mirroring. Basically, if our computer has two hard drives, we can use both disks to set up a mirrored or striped system. The usual caveats exist, including the fact that all existing data may be erased -- so, begin by making sure you have a full backup of all your data, and also that the computer can be safely formatted with no ill-effects (i.e. please do not try this out on a computer you need to work on within the next hour or two…).**

La deuxième méthode consiste à configurer une matrice RAID en utilisant le sous-système md (multiple-disk) intégré au noyau Linux. Des utilitaires tels que mdadm nous donnent accès au système, qui est assez mûr et fonctionne bien. Mais l'interface et les commandes ne sont pas toujours faciles à utiliser, ce qui est un peu dommage et c'est aussi la raison pour laquelle je n'irai pas plus loin dans ce système. Les utilisateurs intéressés peuvent se référer à l'article de Jan Mussche « Installer Mint sur un ensemble de deux disques RAID 0 » dans le numéro 104 du Full Circle - passez du RAID 0 (striping) au RAID 1 (mirroring) et les bases sont à peu près les mêmes. Dans ce cas, le « branchement à chaud » de nouveaux disques sera possible si le matériel de votre ordinateur le permet, ce qui n'est généralement pas le cas pour les ordinateurs grand public et leurs disques. L'ajout de nouveaux disques aux matrices existantes est possible par logiciel, mais nécessite une certaine familiarité avec les commandes.

Miroir ou extension avec BTRFS

Il nous reste donc deux systèmes qui ne sont pas basés sur la gestion de disques individuels, mais de systèmes de fichiers entiers. Dans le FCM n° 94, j'ai parlé du système de fichiers B-tree (BTRFS) et de certaines de ses applications. Ce système de fichiers a encore évolué depuis, au point que je le considère comme mûr et que je l'utilise sur tous mes ordinateurs (oui, je mange ma propre nourriture pour chiens !). Plus précisément, l'installeur d'Ubuntu, et celui de la plupart des autres distributions Linux modernes, prend en charge l'installation de notre système sur un volume btrfs. GRUB peut également utiliser des volumes btrfs, donc très peu de manipulations sont nécessaires pour mettre en place un miroir. En gros, si notre ordinateur possède deux disques durs, nous pouvons utiliser les deux disques pour configurer un système en mirroring ou en striping. Les avertissements habituels existent, y compris le fait que toutes les données existantes peuvent être effacées ; donc, commencez par vous assurer que vous avez une sauvegarde complète de toutes vos données, et aussi que l'ordinateur peut être formaté en toute sécurité sans effets néfastes (c'est-à-dire, s'il vous plaît, n'essayez pas ceci sur un ordinateur sur lequel vous devez travailler dans l'heure ou les deux heures qui suivent...).


**In the following examples, I will be using two rotational hard drives connected via USB to demonstrate the principles. In all cases, a single partition of 100 GByte size will be created on each drive.

Boot from the USB live image as usual, install the operating system using ubiquity on the first hard disk. When you get to the hard drive selection, create a partition. In my example, I will be using Kubuntu 20.04, and the disk to install to is /dev/sdc. Please do verify you are using the correct disk -- perhaps twice – better than just once!

 Boot from our new system, as usual. Now, using our tools of choice for partitioning (fdisk, gfdisk, KDE Partition Manager...), create a single partition on your second hard drive. It is not necessary to format it as btrfs, since whatever format we use will be overwritten.

We then add the second drive’s partition to the existing partition (containing our operating system). This can be done with the computer actually running the system. Supposing our main partition on the first drive with the operating system is /dev/sda1, and the new partition on the second drive is /dev/scd1, we would issue commands such as these:

$ sudo bash

# btrfs dev add /dev/sdc1 / -f

# btrfs fil show
Label: none  uuid: aeb12e81-f5b1-4a48-b80d-d64624867456
Total devices 2 FS bytes used 8.13GiB
devid    1 size 93.13GiB used 11.02GiB path /dev/sda1
devid    2 size 97.66GiB used 0.00B path /dev/sdc1**

Dans les exemples suivants, je vais utiliser deux disques durs rotatifs connectés par USB pour démontrer les principes. Dans tous les cas, une seule partition de 100 GB sera créée sur chaque disque.

Démarrez à partir de l'image Live USB comme d'habitude, installez le système d'exploitation en utilisant ubiquity sur le premier disque dur. Lorsque vous arrivez à la sélection du disque dur, créez une partition. Dans mon exemple, je vais utiliser Kubuntu 20.04, et le disque à installer est /dev/sdc. Vérifiez bien que vous utilisez le bon disque, peut-être deux fois, c'est mieux qu'une seule !

Démarrez votre nouveau système, comme d'habitude. Maintenant, en utilisant les outils de notre choix pour le partitionnement (fdisk, gfdisk, KDE Partition Manager...), créez une partition unique sur votre second disque dur. Il n'est pas nécessaire de la formater en btrfs, puisque le format que nous utilisons sera écrasé.

Nous ajoutons ensuite la partition du second disque à la partition existante (contenant notre système d'exploitation). Cela peut être fait avec l'ordinateur qui exécute le système. Supposons que notre partition principale sur le premier disque avec le système d'exploitation soit /dev/sda1, et que la nouvelle partition sur le second disque soit /dev/scd1, nous devrions lancer des commandes telles que celles-ci :

$ sudo bash

# btrfs dev add /dev/sdc1 / -f

# btrfs fil show
Label: none  uuid: aeb12e81-f5b1-4a48-b80d-d64624867456
Total devices 2 FS bytes used 8.13GiB
devid    1 size 93.13GiB used 11.02GiB path /dev/sda1
devid    2 size 97.66GiB used 0.00B path /dev/sdc1


**At this point, the two separate partitions have been combined into a single BTRFS file system. With these two commands, we have a striped unit with a total capacity of about 200 GBytes. If striping (RAID-0) is desired, stop here.

Mirroring (or RAID-1) has not yet been implemented, and we will proceed to do so by converting our striped unit into a mirrored one. We will be using the fact that the file system is currently mounted on / (i.e. is the root file system). Be aware this process may take some time, especially if partitions’ sizes are in the TeraByte range:

# btrfs balance start -dconvert=raid1 -mconvert=raid1 /

This converts both our data (-dconvert) and filesystem metadata (-mconvert) into RAID-1, effectively writing a second copy of each item on the other disk. Our two partitions should not report a similar amount of space being used. That’s it; we have a mirrored unit and our data will from this point on be effectively duplicated with one copy on each partition.

Please note that both partitions are not quite the exact same size. With BTRFS, this is not an issue for striping. With mirroring, however, some space will be lost with unequal partitions. As a general rule of thumb, the final capacity of our mirrored drive will be about equal to that of the smallest of our two partitions.**

À ce stade, les deux partitions séparées ont été combinées en un seul système de fichiers BTRFS. Avec ces deux commandes, nous avons une unité stripée avec une capacité totale d'environ 200 Go. Si c'est le striping (RAID-0) qui est souhaité, arrêtez-vous ici.

La mise en miroir (ou RAID-1) n'a pas encore été implémentée, et nous allons procéder à sa mise en place en convertissant notre unité stripée en une unité en miroir. Nous allons utiliser le fait que le système de fichiers est actuellement monté sur / (c'est-à-dire qu'il s'agit du système de fichiers racine). Soyez conscient que ce processus peut prendre un certain temps, surtout si la taille des partitions est de l'ordre du Teraoctet :

# btrfs balance start -dconvert=raid1 -mconvert=raid1 /

Cela convertit à la fois nos données (-dconvert) et les métadonnées du système de fichiers (-mconvert) en RAID-1, en écrivant effectivement une deuxième copie de chaque élément sur l'autre disque. Nos deux partitions ne devraient pas montrer une quantité similaire d'espace utilisé. Voilà, nous avons une unité en miroir et nos données seront dorénavant effectivement dupliquées avec une copie sur chaque partition.

Veuillez noter que les deux partitions n'ont pas exactement la même taille. Avec BTRFS, ce n'est pas un problème pour le striping. Avec la mise en miroir, cependant, un peu d'espace sera perdu avec des partitions inégales. En règle générale, la capacité finale de notre disque miroir sera à peu près égale à celle de la plus petite de nos deux partitions.


**Before continuing with our final option, let’s consider recovery from a failed disk. With BTRFS, if we are booting from a mirrored filesystem, the boot process will not continue at the point at which the Linux kernel mounts the drive. To get past that, we need to boot from another medium – an Ubuntu live image on a USB thumb drive is fine -- and fix the bad BTRFS volume. We have two choices, both of which include removing the offending bad drive. On the one hand, if we have a spare physical drive to plug in, we can physically replace the bad unit and then run the “btrfs replace” command to restore the array to operation. On the other, if we have no physical spares available at the time, we can re-balance the BTRFS volume to single-disk mode, and remove the bad drive using the “btrfs balance” and “btrfs remove” commands. At a later date – better sooner than later -- a second, working disk may be partitioned and added to the system as described above.

Mirroring and striping with ZFS

Although ZFS (at this time, the acronym is given no precise meaning) is an old player in the server market with Sun Microsystems behind it, it took some time for this technology to come to Linux. OpenZFS is gaining traction in the Linux kernel and Ubuntu distribution worlds, though perhaps not as swiftly as some server administrators would like. **

Avant de poursuivre avec notre dernière option, examinons la récupération d'un disque défaillant. Avec BTRFS, si nous démarrons à partir d'un système de fichiers miroir, le processus de démarrage ne se poursuivra pas au moment où le noyau Linux monte le disque. Pour contourner ce problème, nous devons démarrer à partir d'un autre support - une image Live d'Ubuntu sur une clé USB est parfaite - et réparer le volume BTRFS défectueux. Nous avons deux choix, qui incluent tous deux la suppression du disque défectueux. D'une part, si nous avons un disque physique de rechange à brancher, nous pouvons remplacer physiquement l'unité défectueuse et ensuite exécuter la commande « btrfs replace » pour restaurer le fonctionnement de la matrice. D'autre part, si nous n'avons pas de disque physique de rechange disponible à ce moment-là, nous pouvons rééquilibrer le volume BTRFS en mode monodisque et retirer le disque défectueux à l'aide des commandes « btrfs balance » et « btrfs remove ». À une date ultérieure - mieux vaut tôt que tard - un deuxième disque fonctionnel peut être partitionné et ajouté au système comme décrit ci-dessus.

Miroir et extension avec ZFS

Bien que ZFS (pour l'instant, l'acronyme n'a pas de signification précise) soit un vieil acteur sur le marché des serveurs avec Sun Microsystems derrière lui, il a fallu du temps pour que cette technologie arrive sur Linux. OpenZFS gagne du terrain dans le monde du noyau Linux et des distributions Ubuntu, mais peut-être pas aussi rapidement que certains administrateurs de serveurs le souhaiteraient.


**ZFS file systems share many characteristics with BTRFS, though some details are different. For example, with ZFS, a virtual device (vdev) may be a single write unit, or may implement mirroring or other forms of data duplication -- but it cannot change from one scheme to another as can BTRFS. Thus, when a vdev is created, one must specify from the onset if we want mirroring to happen, or not. A second feature is that ZFS units are usually mounted automatically by the ZFS subsystem, without needing any entries in the system configuration. In brief, file /etc/fstab may contain zero entries on a system that uses only ZFS units. Finally, in current versions of Ubuntu, ZFS drivers are not part of the basic install, but need to be added through various apt packages.

For interested readers, there is a nice writeup by Jim Salter on ArsTechnica. Though server-focussed, it should give you a good initial presentation to fully understand the specific strengths (and quirks) of ZFS over other file systems: https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/ . **

Les systèmes de fichiers ZFS partagent de nombreuses caractéristiques avec BTRFS, bien que certains détails soient différents. Par exemple, avec ZFS, un périphérique virtuel (vdev) peut être une unité d'écriture unique ou peut mettre en œuvre la mise en miroir ou d'autres formes de duplication de données - mais il ne peut pas passer d'un schéma à un autre comme peut le faire BTRFS. Ainsi, lorsqu'un vdev est créé, il faut spécifier dès le départ si l'on souhaite que la mise en miroir se produise ou non. Une deuxième caractéristique est que les unités ZFS sont généralement montées automatiquement par le sous-système ZFS, sans nécessiter d'entrées dans la configuration du système. En bref, le fichier /etc/fstab peut contenir zéro entrée sur un système qui utilise uniquement des unités ZFS. Enfin, dans les versions actuelles d'Ubuntu, les pilotes ZFS ne font pas partie de l'installation de base, mais doivent être ajoutés via divers paquets apt.

Pour les lecteurs intéressés, il y a un bon article de Jim Salter sur ArsTechnica. Bien que centré sur les serveurs, il devrait vous donner une bonne présentation initiale pour comprendre pleinement les forces spécifiques (et les bizarreries) de ZFS par rapport aux autres systèmes de fichiers : https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/ .


**On Debian-based distributions such as Ubuntu, things have come on to the point that there has been talk of offering to install recent versions on a root ZFS file system, at least as a beta feature. As a matter of personal preference, for the time being I am steering away from this option, at least until ZFS tools mature slightly (they are now shown to be at version 0.8.4) and are included out-of-the-box on all Ubuntu and derivatives’ live boot media. The reasoning here is that, while ZFS does have some very nifty features, the path to recovering data from a crashed boot volume – and please note we are speaking only of a boot volume -- is a tad complex for regular users. For this reason, in the following example I will be working with:
•  A root file system on /dev/sda1 (first partition of our main hard drive), with an existing Kubuntu 20.04 installation. This is actually the very same BTRFS unit used previously. Which actual filesystem is used is not important, any familiar options such as ext4 or btrfs should work well.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  7,7G   36G  18% /

•  Two partitions, /dev/sda2 and /dev/sdc1. These will be combined in a ZFS pool to hold user data.**

Sur les distributions basées sur Debian telles qu'Ubuntu, les choses ont évolué au point qu'il a été question de proposer l'installation de versions récentes sur un système de fichiers ZFS racine, au moins en tant que fonctionnalité bêta. Pour des raisons de préférence personnelle, j'évite pour l'instant cette option, du moins jusqu'à ce que les outils ZFS évoluent légèrement (ils en sont maintenant à la version 0.8.4) et qu'ils soient inclus dans tous les supports de démarrage d'Ubuntu et de ses dérivés. Le raisonnement est le suivant : bien que ZFS ait des fonctionnalités très intéressantes, le chemin pour récupérer des données à partir d'un volume de démarrage planté - et veuillez noter que nous parlons uniquement d'un volume de démarrage - est un peu complexe pour les utilisateurs ordinaires. Pour cette raison, dans l'exemple suivant, je vais travailler avec :
••Un système de fichiers racine sur /dev/sda1 (première partition de notre disque dur principal), avec une installation Kubuntu 20.04 existante. Il s'agit en fait de la même unité BTRFS utilisée précédemment. Le système de fichiers utilisé n'est pas important, toutes les options familières telles que ext4 ou btrfs devraient fonctionner.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  7,7G   36G  18% /

••Deux partitions, /dev/sda2 et /dev/sdc1. Elles seront combinées dans un pool ZFS pour contenir les données de l'utilisateur.


**The purpose of the root file system is just to hold our operating system, and to do so separately from user data. This means it can be formatted easily without affecting user data, or even replaced by a partition on another disk (or even a live media) at a pinch. The ZFS pool will be mounted on /home, to hold user data.

Before beginning, let us install the required packages. BTRFS is integrated into current Linux kernels, but ZFS is not. So, we will need:


# apt update ; apt install zfs-dkms zfsutils 

As previously, begin by creating the appropriate partitions. Since we will not be using the root partition for ZFS, we will leave it alone and create /dev/sda2 and /dev/sdc1, both with about the same capacity. In our case, I will be using 400 GBytes each.

Now, let us create a zpool that uses striping to combine the two partitions. It is traditional to call this zpool the tank, but feel free to choose your own name.

# zpool create tank /dev/sda2 /dev/sdc1 -f
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  7,7G   36G  18% /
tank            756G  128K  756G   1% /tank**

Le but du système de fichiers racine est simplement de contenir notre système d'exploitation et de le faire séparément des données utilisateur. Cela signifie qu'il peut être formaté facilement sans affecter les données de l'utilisateur, ou même remplacé par une partition sur un autre disque (ou même un média vivant) à la rigueur. Le pool ZFS sera monté sur /home, pour contenir les données utilisateur.

Avant de commencer, installons les paquets nécessaires. BTRFS est intégré dans les noyaux Linux actuels, mais pas ZFS. Nous aurons donc besoin de :

# apt update ; apt install zfs-dkms zfsutils 

Comme précédemment, commencez par créer les partitions appropriées. Puisque nous n'utiliserons pas la partition racine pour ZFS, nous la laisserons tranquille et créerons /dev/sda2 et /dev/sdc1, tous deux ayant à peu près la même capacité. Dans notre cas, j'utiliserai 400 Goctets chacun.

Maintenant, créons un zpool qui utilise le striping pour combiner les deux partitions. Il est traditionnel d'appeler « tank » ce zpool, mais sentez-vous libre de choisir votre propre nom.

# zpool create tank /dev/sda2 /dev/sdc1 -f
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  7,7G   36G  18% /
tank            756G  128K  756G   1% /tank


**Each partition is of about 400 GBytes, but in combination they yield 756 GBytes. Note that the new zpool has automatically been mounted as /tank. 

Within the zpool, we will now create a filesystem (vdev) called home, which may expand to use up all the space available.

# zfs create tank/home
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  7,7G   36G  18% /
tank            756G  128K  756G   1% /tank
tank/home       756G  128K  756G   1% /tank/home

The new filesystem has also been mounted automatically, on /tank/home.

We now need to transfer over the contents of our /home directory, since this is where we will be mounting our new filesystem. 

# mv /home/* /tank/home/**

Chaque partition est d'environ 400 Goctets, mais combinées elles donnent 756 Go. Notez que le nouveau zpool a été automatiquement monté comme /tank. 

Dans le zpool, nous allons maintenant créer un système de fichiers (vdev) appelé home, qui peut s'étendre pour utiliser tout l'espace disponible.

# zfs create tank/home
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  7,7G   36G  18% /
tank            756G  128K  756G   1% /tank
tank/home       756G  128K  756G   1% /tank/home

Le nouveau système de fichiers a également été monté automatiquement, sur /tank/home.

Nous devons maintenant transférer le contenu de notre répertoire /home, puisque c'est là que nous allons monter notre nouveau système de fichiers. 

# mv /home/* /tank/home/


**We actually need to move the files (and not merely make a copy) since the /home directory will need to be empty. Otherwise, the ZFS filesystem will refuse to mount on a non-empty directory.

Finally, we program the new filesystem to mount automatically on /home.

# zfs set mountpoint=/home tank/home

Now, reboot. The system should come up with tank/home mounted on /home:

$ mount
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro)
tank/home on /home type zfs (rw,xattr,noacl)
tank on /tank type zfs (rw,xattr,noacl)

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  5,6G   38G  13% /
tank/home       756G   36M  756G   1% /home
tank            756G   36M  756G   1% /tank

As can be seen, the new ZFS vdev is now mounted in its place on /home, with the two striped volumes giving us the expected combined space.**

Nous devons en fait déplacer les fichiers (et pas seulement en faire une copie) puisque le répertoire /home devra être vide. Sinon, le système de fichiers ZFS refusera de monter sur un répertoire non vide.

Enfin, nous programmons le nouveau système de fichiers pour qu'il se monte automatiquement sur /home.

# zfs set mountpoint=/home tank/home

Maintenant, redémarrez. Le système devrait se réveiller avec tank/home monté sur /home :

$ mount
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro)
tank/home on /home type zfs (rw,xattr,noacl)
tank on /tank type zfs (rw,xattr,noacl)

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        46G  5,6G   38G  13% /
tank/home       756G   36M  756G   1% /home
tank            756G   36M  756G   1% /tank

Comme on peut le voir, le nouveau vdev ZFS est maintenant monté à sa place sur /home, avec les deux volumes stripés nous donnant l'espace combiné attendu.


**With ZFS, to create a mirrored zpool instead of striped, the appropriate syntax would simply have been:

# zpool create tank mirror /dev/sda2 /dev/sdc1 -f

Please note the “mirror” keyword. Other commands would be the same in either case, especially the creation of the ZFS filesystem (vdev) within the zpool.

Some final thoughts

A decade ago, mirroring and striping were options that would have seemed exotic, or quite frankly difficult to use, to many users. Even today, systems administrators can have cause to rely on dedicated hardware to set up such arrays. However, the spread of BTRFS and ZFS gives regular users – albeit those with a rather technical bent -- the option of creating mirrored or striped units using only software that is available with the Linux kernel.

Both technical solutions have their proponents, with some very good reasons on either side -- and a tendency to be quite vocal about it at times. Since our purpose is not to provoke an all-out flame war, let us merely suggest that BTRFS has perhaps a tad more flexibility as regards converting striped units into mirrored and vice-versa, can more easily extend an existing unit – even on the fly in a working system -- and is also slightly better integrated into standard kernels. Setting up a mirrored root partition with BTRFS is also marginally easier than with ZFS. On the other hand, the strong points of ZFS include more flexibility setting up and mounting both zpools and vdevs in various configurations, and is more similar to the setup used in many large servers.**

Avec ZFS, pour créer un zpool en mirroring plutôt qu'en striping, la syntaxe appropriée aurait simplement été :

# zpool create tank mirror /dev/sda2 /dev/sdc1 -f

Veuillez noter le mot clé « mirror ». Les autres commandes seraient les mêmes dans les deux cas, en particulier la création du système de fichiers ZFS (vdev) dans le zpool.

Quelques réflexions finales

Il y a dix ans, le mirroring et le striping étaient des options qui auraient semblé exotiques, ou franchement difficiles à utiliser, à de nombreux utilisateurs. Même aujourd'hui, les administrateurs de systèmes peuvent avoir des raisons de compter sur du matériel dédié pour configurer de telles matrices. Cependant, la diffusion de BTRFS et de ZFS donne aux utilisateurs ordinaires - plutôt ceux qui ont un penchant technique - la possibilité de créer des unités en miroir ou en extension en utilisant uniquement un logiciel disponible dans le noyau Linux.

Les deux solutions techniques ont leurs partisans, avec de très bonnes raisons de part et d'autre, et une tendance à être parfois très bruyants à ce sujet. Notre but n'étant pas de provoquer une guerre de mots, nous nous contenterons de suggérer que BTRFS a peut-être un peu plus de flexibilité pour convertir des unités étendues en unités mirrorées et vice-versa, qu'il peut plus facilement étendre une unité existante - même à la volée dans un système en fonctionnement - et qu'il est aussi légèrement mieux intégré aux noyaux standard. La configuration d'une partition racine en miroir avec BTRFS est également légèrement plus facile qu'avec ZFS. D'un autre côté, les points forts de ZFS incluent une plus grande flexibilité dans la mise en place et le montage des zpools et des vdevs dans diverses configurations, et est plus similaire à la configuration utilisée dans de nombreux grands serveurs.


**Additionally, both ZFS and BTRFS feature snapshots, which facilitates rolling back system changes in the event of a disaster, which is perhaps better integrated into the GRUB bootloader under OpenSuSE. They may also be used as a backup mechanism, since snapshots can be transferred between systems using the send-receive process.

All this opens interesting perspectives for the interested student of systems management -- or for the advanced user. However, we would suggest to begin by testing out either or both systems described here on a spare computer, not using them as your main system (i.e. on data you depend upon) until you feel thoroughly at home with their syntax and quirks.**

De plus, ZFS et BTRFS proposent tous deux des instantanés, ce qui facilite le retour en arrière des modifications du système en cas de catastrophe, ce qui est peut-être mieux intégré dans le chargeur de démarrage GRUB sous OpenSuSE. Ils peuvent également être utilisés comme mécanisme de sauvegarde, puisque les instantanés peuvent être transférés entre les systèmes en utilisant le processus send-receive.

Tout cela ouvre des perspectives intéressantes pour l'étudiant intéressé par la gestion des systèmes, ou pour l'utilisateur avancé. Cependant, nous suggérons de commencer par tester l'un ou l'autre ou les deux systèmes décrits ici sur un ordinateur de rechange, sans les utiliser comme système principal (c'est-à-dire pour les données dont vous dépendez) jusqu'à ce que vous vous sentiez parfaitement à l'aise avec leur syntaxe et leurs particularités.