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 tete 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 !!!
Voilà... je vais m'arreter là... fatigué....
Babouilles à tous, j'espere que ces quelques lignes vous auront éclairé
sur les objectifs de ReiserFS !
# REISERFS - Dernier épisode (snif)
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 5.
*** 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 tete 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 !!!
Voilà... je vais m'arreter là... fatigué....
Babouilles à tous, j'espere que ces quelques lignes vous auront éclairé
sur les objectifs de ReiserFS !
-Jedi.