jan
23
Classé dans (Bidouille, Libre / Open Source) par Xavv le 23-01-2011

Le SSD et BTRFS, comment changent-ils notre manière d’aborder le stockage des données ?

« My SSD is faster than you HDD !», tel est le slogan d’OCZ, le célèbre constructeur de composants pour micro-ordinateur qui s’est notamment fait connaitre pour ses « disques durs » SSD.

Mais qu’est ce que le SSD, Solid State Drive, change vraiment au quotidien et comment en tirer un maximum ?

Concepts de base

1.1 le support de type « block »

Pour commencer, faisons une rapide description des changements au niveau même de la conception et du fonctionnement de ce type de support de stockage avec les disques dur « classiques » que nous connaissons si bien.

Un disque dur est composé :

  • d’un ou plusieurs plateau(x) magnétique(s) : les disques ;

  • d’une ou plusieurs tête(s) de lecture ;

  • de plusieurs moteurs devant actionner la rotation des plateaux et l’amplitude des têtes ;

Dans l’univers du stockage des données en informatique, ce type de support est appelé périphérique de type « block ». Chaque piste des disques magnétiques sont découpé en secteurs, regroupés par le système et les appplications en « blocks » qui vont être lus et écris.

Pour accéder à ces « blocks », une première technique d’adressage était le CHS, Cylinder, Head, Sector, dont on comprend très bien le principe.

C’est ainsi que sont apparus par la suite les partitions, des « portions » de « blocks », qui pouvaient être dédiées à des utilisations différentes et qui étaient indépendantes (les données présentes sur une partition ne peuvent partager un même espace qu’une autre partition. Chacune possède un système de fichiers différents).

Avec le temps, sur la plateforme Linux, sont apparus les gestionnaires de volumes logiques qui permettent de faire face aux limitations des partitions en offrant comme principale fonctionnalité la possibilité de redimensionner les partitions « à chaud » et sans devoir formater les « volumes » et perdre ainsi les données présentes. Ces gestionnaires de volumes, comme LVM, permettent également d’utiliser plusieurs disques dur physiques comme si il ne s’agissait que d’un seul et unique « support » de stockage.

1.2 Gestion des supports :

Traditionnellement, nous avons les disques « physiques » :

/dev/sdX

et leurs partitions

/dev/sdXY

Le RAID, matériel ou logiciel, et le LVM créent de nouveaux périphériques de types « block » sur Linux :

/dev/mdX

et

/dev/dm-X

Avec respectivement le MD-Driver et le « device-mapper », le RAID et LVM ont besoins de s’intercaler entre le pilote qui gère le matériel physique et le système de fichiers du système qui réalise les manipulations des fichiers. C’est eux qui gèrent exactement l’emplacement sur le disque du « block » auquel le système de fichiers essaye d’accéder.

Couches RAID, LVM, Filesystem

2 Le SSD et BTRFS

2.1 BTRFS

Jusque là, nous avions donc l’habitude de traiter et de « manipuler » des concepts « rigides » dans leur fonctionnement (même si le LVM semble apporter plus de souplesse dans cette « rigidité » apparente).

En effet, les partitions ou volumes sont fixes et indépendants. Chacun possède son système de fichiers qui peut varier et ainsi répondre aux différents cas d’utilisations. Les données présentes sur l’un de ces volumes ne sont pas en interaction directe avec les autres données et lorsqu’un volume est « plein », il ne va pas stocker ses données sur un autre volume.

BTRFS est un système de fichiers que de nombreuses personnes attendent avec impatience car il intègre des fonctionnalités nouvelles par rapports aux autres systèmes de fichiers.

BTRFS a été conçu dès le début avec un soucis d’administration. Ainsi, il intègre les concepts de « volumes » et de « Snapshot », jusque là réservés à LVM. Il permet comme ce dernier de gérer plusieurs disques « physiques » en se répartissant sur ces derniers et en permettant le redimensionnement à « chaud » aussi bien en agrandissement qu’en rétrécissement.

De part cette gestion de supports physiques, il offre également les concepts de RAID à un certains niveau et permet une redondance et une intégrité des données.

2.2 Le SSD

Nous avons donc vu que par le passé tout les systèmes et éléments ont été conçus pour fonctionner avec des périphériques de types « blocks ». Les limites des disques durs « classiques » tiennent principalement en 2 points :

  • Leur faiblesse mécanique, qui fait que nous redoutons la panne de ce derniers ;

  • Leur temps d’accès aux données, où il est nécessaires d’actionner les disques et d’attendre que la tête de lecture atteigne la bonne piste et le bon secteur pour lire ou écrire une donnée ;

Le SSD vient modifier quelque peut cette données. En effet, avec le SSD plus de disques, le support de stockage est un ensemble de puces. Il n’est plus nécessaires d’attendre que la tête atteigne le « block » puisque chaque puce peut être accédée directement. La complexité passe en O(1) et la vitesse d’accès est impressionnantes.

Si avec les puces à mémoire « flash », nous gagnons en vitesse, avec le temps nous nous sommes aperçu que pour conserver les performances optimales, il est nécessaires de « vider » et récrire les données présentes sur chaque puce, c’est ce qu’on appelle le TRIM :

« La commande TRIM, disponible sur la plupart des modèles récents de SSD, permet aux systèmes d’exploitation modernes, tels que les systèmes Linux à partir du noyau 2.6.33 ou le système d’exploitation Microsoft à partir de Windows 7, d’éviter que les performances ne se dégradent avec le temps. Elle sert à notifier le SSD lors de l’effacement d’un fichier. Le contrôleur du SSD peut alors effacer les cellules de mémoire flash anciennement utilisées, afin d’optimiser les écritures ultérieures qui pourront alors être effectuées sans avoir à réaliser l’effacement préalable imposé par la technologie de la mémoire flash. »

Wikipedia

Typiquement, cela revient à « bouger » physiquement les données d’une puce à l’autre à chaque écriture. Les performances des SSD se dégradent donc lorsqu’ils sont presque au maximum de leur capacité et où il n’y a plus de puce libre pour déplacer les données.

Vous allez me dire …. hum, ça fait un gros désavantage par rapport aux disques « classiques ».

3 En pratique ça donne quoi ?

Alors en pratique, il est toujours possible d’utiliser les SSD comme nous avions l’habitude de le faire :

  • Des partitions ;
  • Un pti LVM ;
  • Différents FS
  • et le tour est joué.

Les « firmware » des SSD réalisent des opérations de translation avec le fonctionnement par « block » que nous avions l’habitude d’utiliser.

Mais bon, en ce moment, c’est pas encore donné un disque dur SSD (compter 130€ les 60Go pour un disque performant). Comment fait on pour garantir les performances du « disque » ?

Encore une fois la réponse varient en fonction de votre utilisation. Pour ma part, je vais vous détailler mon expérience avec 1 seule « disque » sur un ordinateur portable.

3.1 Le TRIM

Première chose, on se dit qu’on va utiliser le TRIM. Ok, mais adieux LVM et RAID logiciel ! En effet, comme nous l’avons vu, ces derniers doivent gérer exactement l’emplacement des « block » pour assurer leurs différentes fonctionnalités.

Bon, Ok, pas de RAID, ce n’est pas une grande perte pour mon Laptop, par contre, pas de LVM… ça veut dire que je suis obligé d’utiliser les partitions pour séparer mes données.

Oui, mais les partitions, c’est tout aussi limitant pour un SSD avec le TRIM, il faut qu’il puisse utiliser tout l’espace pour manipuler les données. Je mets tout dans une seule partition alors !

3.2 Le FS

C’est parti, on met tout de même les partitions obligatoires pour le Swap et le boot en ext2 (les habitudes sont tenaces, mais je vais justifier par la suite pourquoi une partition /boot).

Maintenant, quel système de fichier utiliser pour “/” ? Avec Fedora 14, ou une autre, la référence semble être Ext4. Oui, mais qu’apport Ext4 : la gestion des grands fichiers…. Cool, mais ce n’est pas ce que je cherche. J’utilise un SSD, par ce que j’en ai mare de voir la diode du DD s’allumer et entendre ce dernier gratter quand il doit charger les petits fichiers de configuration du système. Donc pour les grands fichiers Ext4 ok, mais sur un disque dur « classique ».

Eh, mais attendez, BTRFS possède un « mode » ssd, ou plus tôt une option de montage « ssd ». Cool ! En plus, il utilise des Arbres et la même technique que ReiserFS pour stocker les petits fichiers, nikel !

C’est parti, après l’installation de Fedora 14 seule sur le SSD et BTRFS sur / , nous obtenons :


root@jumper:/home/xakra# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Sat Jan 22 17:56:59 2011
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk’
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#

UUID=3289932e-544a-4bf0-8c82-9170e762ad05 / btrfs defaults,noatime,nodiratime,ssd,discard 1 1

UUID=cdad8682-effd-4138-8773-33cb4ce2d277 /boot ext2 defaults 1 2

UUID=1e0fa5d4-e062-4386-ad6c-46d852a9ebd8 swap swap defaults 0 0

tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0

Dans les options de montage, signalons :

  • noatime, nodiratime : classiques pour éviter de mettre à jour les métadonnées du FS à tout bout de champs, ça évite au SSD de bosser :D ;

  • ssd : le fameux, qui dès le système de fichiers, essaye de trouver des régions du disque non utilisées pour réaliser l’allocation ;

  • discard : d’après la documentation de Fedora 14, pour activer la gestion du TRIM du noyau Linux, il faut utiliser cette option de montage.

3.3Autres fonctionnalités

Yum Snapshot

Un truck que les Geeks fans de nouveautés adorent déjà est le concept de Snapshot intégré à BTRFS. Dans Fedora, un plugin pour yum existe déjà : yum-plugin-fs-snapshot.

Ce plugin réalise automatiquement un snapshot du système de fichiers “/” avant chaque opération d’installation, de mise à jour ou de suppression. Ainsi, cela permet de tester une mise à jour, et si elle rend votre installation instable, on « roll back » et le tour est joué !

Remarque : ce plugin semble également fonctionner avec LVM…

Dans BTRFS, un Snapshot est un « subvolume ». De base, un « subvolume » est un arbre de gestion du FS qui possède les métadonnées et les pointeurs vers vos données. Puisque BTRFS fonctionne sur le principe de « Copy On Write », à chaque fois que l’on fait une modification d’un fichier, c’est comme si on écrivait de nouvelles données. Les anciennes sont conservées et seul les pointeurs vers les données « actives » sont mis à jour ! Du coup, on perd presque pas de place avec ce principe puisque seule les métadonnées sont répliquées.

Je vous renvois vers ce lien qui explique un peu plus en détails le concept :

https://btrfs.wiki.kernel.org/index.php/SysadminGuide

Subvolumes

Bon, pour éviter de « Snapshoter » des données qui n’ont pas à l’être à chaque update, je vais peut être créer des sous volumes différents pour chaque « volumes » que nous avions à l’époque de LVM.

Comment ça se passe ? MAN :

Création d’un sous volume :

btrfs subvolume create [/]
Create a subvolume in (or in the current directory if is
omitted).

Utilisation d’un sous volume

mount -o defaults,subvol=<name> <device> <mountPoint>

On voit ainsi que la commande « subvolume create » créer le sous volume dans un répertoire « destination ». Hum, si je fais un « subvolume create / home », il se passe quoi ?

On va tester dans /mnt Test :


root@jumper:/mnt# btrfs subvolume create Subvol1
Create subvolume './Subvol1'


root@jumper:

Les commentaires sont clos.