Bon alors on va essayer de résumer un peu la situation...
*** POURQUOI A ETE CREE 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.
Bon, dans le prochain épisode, je tenterai de répondre aux questions
suivantes : quel intéret aujourd'hui, face à Ext2, Ext3, Tux2, XFS et JFS.
Et dans le dernier épisode : le futur.
# REISERFS - Premiere partie
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 5.
*** POURQUOI A ETE CREE 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.
Bon, dans le prochain épisode, je tenterai de répondre aux questions
suivantes : quel intéret aujourd'hui, face à Ext2, Ext3, Tux2, XFS et JFS.
Et dans le dernier épisode : le futur.
-Jedi.