ReiserFS

Note de Newbie #1, l'article ci dessous provient des commentaires de linuxfr.org. Mais bon, comme Jedi a l'air de bien maîtriser son sujet ...

Pourquoi a été créé ReiserFS

Lorsque Monsieur Reiser, Hans de son prénom, étudiait à Berkeley, il a eu comme tous ses petits camarades, une thèse de fin d'étude à rendre. Et en guise de sujet, il a choisi les filesystems. Après avoir étudié un peu tout ce qui avait été fait dans le domaine, il s'est appercu qu'ils reposaient tous sur les memes concepts archaiques :

  • Les données sont organisées dans des fichiers, situés dans une arborescence de répertoires. Ces données se présentent sous la forme d'un triste ensemble linéaire.
  • On peut ajouter des données à la fin d'un fichier, écrire par dessus celles qui sont déjà présentes ou tronquer la fin d'un fichier. C'est tout, aucune autre opération.

    A cause de ces deux points, programmer des applications est souvent un casse-tête. Les applications manipulent des données. Des données structurées. Des données qui ont des liens entre elles. Des données que l'on peut trafiquer dans tous les sens en mémoire. Mais dès l'instant où il faut les sauvegarder, les charger, les indexer sur disque, bref... les placer dans un système de fichiers, c'est la galère. Il faut trouver un moyen de linéariser toutes ces structures, définir une nouvelle représentation qui n'a aucun rapport avec celle en mémoire et qui est à des années lumière d'une idéale représentation théorique. Prenons un exemple simple : une liste chaînée. En mémoire, c'est simple, hop, hop, hop, chaque élément est composé d'un champs qui pointe vers un autre élément. Maintenant effectuons la même chose dans un fichier... oh-oh... ça engendre déjà quelques complications, surtout si toutes ces données sont dynamiques... Il va falloir commencer à se creuser la tête pour imaginer un "format de données", cette chose qui représente la principale source d'incompatibilités et de soucis entre les logiciels... Pour limiter la casse, on peut passer par des moteurs de bases de données, qui nous présentent une interface un peu moins limitée que open/fseek/read/write/ftruncate ... Ces moteurs vont trafiquer des données présentées sous une certaine forme pour finalement les recoder autrement sur disque dur, au prix d'une charge processeur et disque incroyables pour lire quelques malheureux octets. Il existe aussi maintenant des langages tels que XML qui prouvent bien le manque qui existe pour la représentation de données structurées sur un disque dur.

    Plutot que d'employer des artifices ou de demander aux programmeurs d'adapter leurs applications aux limitations d'un filesystem... pourquoi ne pas voir les choses autrement ?

    Par exemple, au lieu d'accéder à des données à l'aide d'un chemin, pourquoi n'y accederait-on pas par mots-clefs ? Si notre application représente facilement des arbres en mémoire, pourquoi ne serait-il pas possible d'avoir un système de fichiers adapté à la structure que l'on utilise ?

    L'idée serait par exemple d'avoir un système de plug-ins, pour que le filesystem s'adapte aux applications. La programmation devient beaucoup plus simple, et les performances sont optimales. Cela permet au passage de mettre les traditionnelles bases de données à la poubelle dans bien des cas.

    Hans Reiser a continué sa reflexion sur l'organisation des fichiers dans les principaux filesystems. Bizarre... une division en 'blocs', un index et une liste de blocs libres, tout ça localisé dans un coin (tout au début du disque pour la plupart, en plein milieu pour HPFS) ... les données elles-memes réparties un peu n'importe comment sur le disque, là où il y a de la place...)

    C'est bizarre... Pourquoi ne pas mettre les méta-données à coté des données concernées ? Ce serait plus simple et plus rapide. Pourquoi cette notion de blocs ? Ne pourrait-on pas placer données et métadonnées dans un seul bloc, voir plusieurs petits fichiers dans un meme bloc ? On gagnerait du coup de l'espace disque et des performances (un seul secteur à lire pour plusieurs fichiers, méta-données et contenu) . Apparemment, tous les filesystems traditionnels ont négligé les petits fichiers.

    Un disque dur est principalement mécanique. Sa pauvre petite tete n'a pas une vitesse infinie. Pourquoi n'essayerait-on pas de placer les données au mieux pour en limiter les déplacements ? Quitte à déplacer et à réorganiser ces données sur le disque pour que, dès qu'un meilleur emplacement pour des données soit disponible, il soit utilisé ?

    Autre reflexion... Se balader dans de gros fichiers prend du temps. Car un gros fichier n'est que très rarement linéaire sur le disque... il est en plusieurs morceaux... Mais... Pourquoi ne pas organiser les données (et pas seulement les indexes) sous forme d'un B-tree ? Il serait alors toujours aussi rapide d'accéder à n'importe quel point d'un fichier. Ah oui il faut rééquilibrer l'arbre régulierement pour que ça reste un b-tree... C'est pas si évident que ça à coder...

    En fait toutes ces idées sont excellentes. Repartir sur de nouvelles bases (après tout très logiques) pour un filesystem est une aventure passionnante. Mais c'est un travail énorme. Le pauvre petit Hans ne pouvait pas faire ça tout seul. Alors, une fois son diplôme en poche, il a fondé Namesys Venture, convaincu quelques investisseurs de lui donner du pognon pour commencer... Et embaucher des programmeurs pour travailler sur le projet. Le moteur de recherche Ecila a été assez rapidement intéressé pour sponsoriser le projet, en particulier pour une indexation par mots-clefs. La société Namesys est née. Elle a ensuite changé de nom pour passer à ReiserFS à cause de quelques escrocs qui ont quitté la barque en cours de route.

    ReiserFS aujourd'hui

    Les performances des versions actuelles de ReiserFS dépendent énormément de ce que l'on en fait. Pour les accès en lecture, c'est en général beaucoup plus rapide qu'Ext2, surtout si l'on s'amuse à faire des déplacement un peu partout dans les fichiers. En écriture... ça dépend. C'est souvent comparable à Ext2, mais la journalisation ajoute quelques limitations. Tout d'abord, les appels à fsync() ou fsyncdata() sont lents. Car actuellement, appeler ces fonctions conduit à une synchronisation complete du journal. Toutes les transactions sont réalisées, y compris celles concernant d'autres fichiers que celui sur lequel on appelle fsync(). Pour cette raison, des logiciels comme les serveurs de mail et les bases de donées sont plus lents en mise à jour avec ReiserFS que Ext2. Solution radicale pour accélérer tout ça : enlever la journalisation.

    ReiserFS est aussi très rapide pour accéder à des répertoires contenant des millions de fichiers. En effet, tous les noms sont indexés dans une table de hash pour les repérer rapidement (c'est ça, le R5 hash, TEA hash, etc...). C'est très intéressant, car pour une application genre 'forum' par exemple, il n'y a aucune honte à coller tous les messages dans un répertoire, un fichier par message. Ca ne pose aucun problème, c'est simple à coder et c'est très rapide. L'Ext2 tire très vite la langue dans des conditions similaires.

    Et pour encore plus de performances dans une telle situation, on peut désormais accéder aux fichiers directement à partir de leur numéro d'inode. Aucune recherche n'est donc effectuée, l'accès est immédiat. Ce sont des travaux qui ont été réalisés pour l'optimisation de Squid, mais d'autres applications peuvent en tirer partie.

    ReiserFS a un autre intéret : il peut vous faire gagner de l'espace disque. Ce sont les 'tails'. Prenez une partition ext2, convertissez-là en ReiserFS et ... oh miracle, vous avez environ 5% de place en plus qu'avant. Tout dépend de la taille des fichiers, mais tous les petits fichiers de config y gagnent.

    D'un autre coté, l'écriture (et surtout le fait d'y ajouter des données) dans ces fichiers 'compactés' est plus lente qu'en temps normal. Vous pouvez accélérer les choses en montant vos filesystems ReiserFS avec l'option '-notail'.

    Sinon, puisque quelqu'un parlait d'un problème avec Lilo... Le problème venait justement de l'histoire des tails. Lilo a du mal à charger des données qui débutent en plein milieu d'un secteur. Un appel système a donc été rajouté sur les versions récentes de ReiserFS pour 'décompacter' un fichier. Cet appel est utilisé sur les versions récentes de Lilo. Votre partition /boot (ou /) peut donc utiliser les tails sans problème, pensez juste à mettre à jour votre Lilo.

    Quid des autres filesystems

    Ext3 : malgré son numéro de version faiblard, il est assez stable. Mais très lent. Trop lent même. Intéret : on peut migrer de ext3 vers ext2 et inversement facilement.
    Tux2 : instable, encore beaucoup de travail à y apporter, mais le concept est intéressant et l'auteur bosse bien dessus.
    XFS et JFS : quelqu'un qui a testé longuement les derniers snapshots peut nous en parler ?
    Quoi qu'il en soit, le meilleur filesystem "traditionnel" (organisation linéaire pour les applications, pas de plug-ins) est à mon avis celui de Netapp. Il a d'ailleurs été programmé par l'équipe qui avait pondu le XFS à l'époque. Mais je doute qu'il soit un jour porté sur nos linuxettes.

    ReiserFS demain

    La version actuelle de ReiserFS (au niveau de l'organisation physique des données) est la 3. D'une version majeure a l'autre, beaucoup de choses sont remises en question. En bref : n'esperez pas relire vos partitions ReiserFS 4 sous un kernel avec ReiserFS 3. Dans l'autre sens, il est possible que ça fonctionne, Hans Reiser s'étant engagé auprès d'Alan Cox à supporter ce format ad vitam eternam. En pratique... on verra. Mais pas de panique cependant : ReiserFS 4 n'est prévu que pour Linux 2.6 (ce qui veut dire qu'en pratique ce sera encore plus tard) .

    A court terme, ReiserFS 3 (TROIS) va implémenter les wandering logs. Pour l'instant, le journal est situé à un endroit fixe du disque, choisi lors du formattage du dur. En dehors des problèmes de déplacement de la tête de lecture, ce n'est pas très fiable d'écrire sans arret dans la meme zone du disque dur. On augmente considérablement ses chances d'obtenir des badblocks. Et des badblocks dans le journal, ce n'est pas bon du tout. Les wandering logs consistent à avoir un journal qui se déplace dans différentes zones du disque (si possible près des données les plus accédées) .

    Toujours à court terme, il y a des chances pour que les disques durs à problème (badblocks) soient un peu mieux gérés que maintenant. Actuellement, en cas de badblock, ReiserFS espere que le disque va faire un remapping transparent des secteurs. Certains disques SCSI le font. Mais si ce n'est pas le cas... hum... pour l'instant vous risquez de paumer des données. Toutes les données de ReiserFS sont stockées sous la forme d'un arbre : si on coupe une branche, il devient difficile de retrouver tout ce qui se trouvait en dessous. En fait, Hans Reiser dit souvent "si on commence à avoir des badblocks, le disque dur ne va pas tarder à lacher de toutes façons, donc il faut changer de dur". Mais bon, tout le monde le saoule pour qu'un traitement des badblocs soit tout de meme implémenté. A mon avis, ce sera fait rapidement, dès que Chris et Vladimir auront un peu de temps, et après les wandering logs.

    Bon sinon pour la v4 ... Quelques idées ont été évoquées et validées. Mais rien n'est sur, et aucune implémentation n'a débuté :

  • Les snapshots à la Netapp.

  • Un filesystem distribué en réseau, pour remplacer les croulants NFS et Coda (projet mort, les développeurs planchent sur Intermezzo qui est actuellement inutilisable, ils testent juste des concepts avec une premiere approche en Perl) . L'idée serait éventuellement d'envisager un partenariat avec GFS (Global Filesystem, excellent projet, mais pas hyper rapide au niveau de l'écriture physique. ReiserFS serait un bon complément).

  • Plus de limitation pour les collisions avec les valeurs de hachage. Je n'ai pas envie de m'étaler là-dessus, mais en gros, à chaque nom de fichier est associé une clef. Si un répertoire contient 127 fois la même clef, on ne peut plus créer de nouveau fichier avec cette clef. Xuan a proposé une solution pour y remédier (en gros, on crée un nouveau tableau de 127 clefs).

  • Les plug-ins !!! Enfin !!!

    N'utilisez pas ReiserFS sur les ordinateurs portables

    Pourquoi donc ? Ce serait bien pratique pour éviter les fsck lorsque les batteries ont lâché un peu tôt ! Oui mais voilà : lorsque les applications ne font plus aucun accès au disque, ReiserFS en profite pour rééquilibrer l'arbre, synchroniser le journal, et plus tard le déplacer.

  • Conséquence positive : pendant les périodes d'inactivité, le filesystem s'optimise.
  • Conséquence négative : le disque dur "gratte" davantage qu'avec Ext2. L'autonomie des notebooks sur batteries est donc réduite.

    Bref sur un portable, utilisez Ext2 et noflushd (http://noflushd.sourceforge.net). N'hésitez pas non plus à compiler vos applis dans un ramdisk (le filesystem swapfs est pratique pour ça) : c'est plus rapide et le disque dur peut rester en veille. Et sur un portable, montez absolument vos partitions en noatime,nodiratime.

    Frank Denis j@4u.net
    http://www.jedi.claranet.fr
    Mardi 16 janvier 2001