

===========================

| Système de fichiers UBIFS |

===========================

|

=====================================

| Couche UBI de factorisation de code |

=====================================

|

=============================

| Couche MTD interne au noyau |

=============================

|

_________________________________

| | | |

====== ===== =========== =========

| NAND | | NOR | | DataFlash | | ECC NOR |

====== ===== =========== =========



Aller plus loin

Depuis plusieurs mois les disques durs basés sur de la mémoire flash , aussi nommés disques SSD , commencent à apparaître dans des machines comme l'EeePC d'Asus ou le MacBook Air d'Apple. De plus il est possible d'acheter ces disques séparément pour les installer dans des ordinateurs de bureau afin d'augmenter leurs performances.Pourtant cette apparition timide sur le marché n'est que le prélude d'un véritable raz de marée programmé par les industriels dans les années à venir.Le monde du logiciel libre est-il prêt à exploiter de façon efficace cette nouvelle technologie ? De nouveaux systèmes de fichiers sont-ils nécessaires et le noyau Linux doit-il être adapté ?Cette dépêche tente de faire le point sur ces questions et d'évaluer les solutions en présence permettant le support des disques SSD. Un disque dur classique est constitué d'un bras de lecture survolant à très courte distance un plateau rotatif magnétisé et tournant à plusieurs milliers de tours par minute. On voit immédiatement tous les inconvénients de cette technologie: la résistance aux chocs est faible car un contact entre le bras et le plateau doit être évité à tout prix. D'autre part la fiabilité et la consommation énergétique sont mauvaises car il y a des pièces mécaniques à mettre en mouvement. Enfin l'accès aux données est lent car le bras de lecture doit se repositionner au dessus des données avant de pouvoir les lire.La promesse des disques SSD est de s'affranchir de tous ces défauts d'un seul coup. En basculant vers cette nouvelle technologie qui ne comporte pas de pièces en mouvement on obtiendrait une bonne résistance aux chocs, une fiabilité de haut niveau, une consommation réduite et des temps d'accès sans commune mesure avec les disques durs traditionnels.Pourtant, outre l'obstacle du prix et de la capacité, il reste un problème important à résoudre afin de profiter pleinement de tous ces avantages. En effet les systèmes de fichiers utilisés jusqu'à présent ont tous été conçus avec les limitations des disques durs en tête et une bonne partie de leur architecture est à revoir.Actuellement les disques SSD utilisent une interface de communication standard (souvent l'interface SATA ) et ils sont vu par le système d'exploitation comme des disques durs classiques. Cela leur permet d'être formaté avec un système de fichiers normal et d'être inséré dans une machine sans problème en dépit du fait qu'ils ne comportent pas des secteurs mais des blocs mémoires Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).Pour faire face à ce problème la technique du " wear levelling " a été développée. Elle consiste schématiquement à enregistrer le nombre d'écritures pour chaque bloc mémoire et à répartir ensuite intelligemment les nouvelles données à écrire de façon à minimiser l'usure de chaque bloc. Des graphiques présentant l'évolution de l'usure d'un disque SSD avec et sans wear levelling sont disponibles sur cette page Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.Il est donc bien plus efficace de créer des systèmes de fichiers spécialement dédiés aux disques SSD et dialoguant directement avec la puce de mémoire flash sans passer par le microcontrôleur de wear levelling. Cet algorithme est ainsi implémenté directement dans le système de fichiers optimisé pour les SSD.C'est pourquoi de nombreux développeurs du monde du logiciel libre se sont lancés dans la conception de nouveaux systèmes de fichiers spécialisés dans les disques SSD. Comme il est de mise dans le monde de Linux la compétition est rude et tous les projets aspirent à devenir le Ext3 de demain. A ce stade de développement il peut être intéressant de passer en revue les concurrents en lice et d'évaluer leurs chances respectives.Le système JFFS (Journaling Flash File System), disponible sous licence GPL, a été écrit à l'origine par la société Axis Communications pour l'antique noyau Linux 2.0. Il a été remplacé par JFFS2 qui, sous les auspices de Red Hat et toujours sous licence GPL, a fait son entrée dans le noyau 2.4.10 en septembre 2001. C'est donc un système vraiment mature qui, malgré des limitations que nous verrons par la suite, représente un choix sans risques.Alors que JFFS première mouture ne fonctionnait qu'avec les mémoires flash NOR et utilisait un mode d'écriture purement circulaire, JFFS2 propose un système bien plus abouti. Tout d'abord la compatibilité avec la mémoire flash NAND , mieux adaptée au stockage d'informations, est assurée. Ensuite les données peuvent être compressées (avec plusieurs algorithmes au choix) ce qui est précieux car les disques SSD ont des capacités de stockage inférieures aux disques durs classiques. Enfin JFFS2 ne fonctionne pas sur un mode d'écriture circulaire comme le faisait JFFS. Avec ce système toutes les écritures s'empilent dans une queue qui écrit en parcourant progressivement tout l'espace disque. C'est une solution simple mais qui implique que toutes les données du disque sont réécrites (même si cela n'était pas nécessaire) et que cela diminue la longévité du disque. Au contraire JFFS2 traite les données par blocs et évite de toucher aux données statiques sur le disque. Comme les blocs mémoires d'un disque SSD sont de grandes tailles (32 Ko ou plus) un ramasse-miettes (garbage collector) est utilisé pour récupérer de la place en fusionnant les données dans des nouveaux blocs afin que les anciens puissent libérer de la place.Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM. Si cette opération n'est que peu pénalisante dans le cas d'un volume de petite taille, elle devient absolument rédhibitoire avec les disques SSD modernes (8 Go et plus).En définitive JFFS2 est un bon système de fichiers et il est bien adapté aux disques flash de faible capacité mais, du fait de son temps de montage et de l'ancienneté de sa conception, il ne peut plus être considéré comme une solution à privilégier. Le monde du libre a clairement besoin d'un remplaçant.Une alternative est le système de fichiers YAFFS (Yet Another Flash File System) développé sous double licence (GPL/commercial) par la société Aleph One. Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD. On peut noter d'autre part que YAFFS a été conçu de façon modulaire afin qu'il puisse être utilisé avec d'autres systèmes d'exploitation (par exemple Microsoft WindowsCE).Une seconde version, YAFFS2, a été introduite afin de respecter la nécessité de n'écrire que le moins de fois possible sur les blocs mémoires et pour permettre l'accès à la mémoire NOR.YAFFS est presque aussi ancien que JFFS2 puisque l'ouverture du CVS date de mai 2002 mais ce système de fichiers n'a jamais vraiment "décollé" dans le monde du libre. La société Aleph One semble vraiment réserver son produit pour le monde de l'embarqué et n'a jamais vraiment cherché à bâtir une communauté de développement. Un des gros problèmes de YAFFS est le fait qu'il n'est pas intégré dans la branche principale du noyau Linux et qu'il n'y a jamais eu de tentative d'inclusion. Pour pouvoir utiliser ce système il est donc nécessaire de le compiler à partir des sources et la documentation n'est pas vraiment à jour . Bien entendu l'évolution rapide du noyau signifie que les risques de non compatibilité avec un système de fichiers externe comme YAFFS sont élevés comme cet exemple le prouve Un autre système de fichiers libre (sous licence GPL) et spécialisé dans la mémoire Flash est également développé dans la perspective de l'arrivée en masse des disques durs de type SSD. LogFS est écrit principalement par Jörn Engel et il est basé sur une écriture séquentielle des données (log-structured approach) qui ne nécessite pas de scan complet du volume au montage. Toute la structure du système de fichiers est donc écrite directement dans le disque ce qui accélère considérablement le montage par rapport à JFFS2. Selon Jörn Engel, sur un disque NAND flash d'une capacité de 1 Go, on passe de 3,3 secondes pour le montage sous JFFS2 à 60 millisecondes avec LogFS.En dépit de ces promesses, l'écriture de LogFS n'est pas réellement terminée et le travail avance lentement puisque Jörn est le seul vrai contributeur. Tant qu'il n'y avait pas de concurrent sérieux pour le titre de "système de fichiers de nouvelle génération pour disques SSD", LogFS pouvait représenter l'avenir (voir cet article de mai 2007). Mais il semble que ce ne soit plus le cas puisqu'un rival très sérieux, UBIFS, vient d'apparaitre récemment.UBI (Unsorted Block Images) est une couche d'abstraction présente dans le noyau Linux depuis la version 2.6.22 et qui permet de gérer les périphériques à base de mémoire NAND flash. C'est un équivalent fonctionnel de LVM mais spécialisé dans la mémoire flash. UBI effectue un mappage entre les blocs logiques de la mémoire flash et les blocs physiques. Elle permet la répartition des écritures sur toute la mémoire (wear levelling) et elle tient compte des blocs mémoires défectueux (bad-block handling). La couche gère également la création de volumes UBI qui peuvent être dynamiquement créés, re-dimensionnés ou supprimés. Un fichier PDF complet sur la conception d'UBI est disponible ici Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau :Les ingénieurs de la firme Nokia, en collaboration avec l'université de Szeged , ont donc travaillé afin de développer UBIFS (UBI file system) et ont récemment présenté le résultat de leurs efforts sur la liste de diffusion du noyau.Comme pour LogFS, il a été décidé de conserver sur le disque Flash l'index de la structure du système de fichiers afin d'éviter de lire l'intégralité du disque. L'ennui c'est qu'un scan de tout le disque est quand même nécessaire lors du montage car la couche UBI en a besoin pour attacher le périphérique . Cependant ce scan se contente de lire les en-tête des blocs les temps de boot sont donc bien plus rapides qu'avec JFFS2.Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone. Le gain en performances est absolument ahurissant () par rapport à l'écriture synchrone de JFFS2.Enfin UBIFS, ou plutôt la couche UBI sous-jacente, gère parfaitement le dysfonctionnement des blocs mémoires (courant avec la mémoire flash) que ce soit lors de la création du système de fichiers ou au cours de la vie du système. LogFS est limité à la gestion des mauvais blocs lors de la création et ne peut les gérer par la suite.Un document détaillé sur le design d'UBIFS est disponible ici JFFS2 est âgé et son temps de montage le rend inadapté pour utiliser les disques modernes de grande taille. YAFFS2 est un bon système pour l'embarqué mais il reste relativement obscur et ne vise pas à intégrer Linux. En définitive il ne reste vraiment en lice que LogFS et UBIFS.Par rapport à son nouveau concurrent LogFS garde l'avantage sur le plan de la compacité du code (environ 8000 lignes contre 11000+30000 pour UBI+UBIFS) et sur le temps de montage. Néanmoins la situation a beaucoup changé et LogFS, qui l'an dernier semblait le candidat le mieux placé pour prendre la place du vénérable JFFS2, a perdu un peu de son éclat depuis l'arrivée d'UBIFS. Ce nouveau système est techniquement plus cohérent puisqu'il s'appuie sur une couche (UBI) déjà présente dans le noyau et les tests semblent montrer que ses performances sont meilleures. Le fait que Nokia soit derrière ce système de fichiers alors que LogFS ne peut compter que sur un seul vrai contributeur est également une indication à prendre en compte en ce qui concerne le rythme de développement.Bien entendu rien n'est encore joué et il faudra surmonter la redoutable épreuve de l'acceptation dans la branche principale avant que nous puissions y voir plus clair dans le domaine des systèmes de fichiers SSD pour Linux.