La version 4 du système de fichiers Reiserfs vient de sortir.
Reiserfs est un système de fichiers journalisé, c'est à dire qu'il apporte un gain de sécurité en terme d'intégrité des données par rapport à un système de fichiers classique. Cette version a été écrite sans utiliser le code de la version précédente, qui sera toujours maintenu pour corriger les bugs le cas échéant. Les développeurs affirment avoir conçu cette nouvelle mouture en portant une attention particulière à la qualité du code.
Reiserfs supporte les transactions atomiques : une modification sur le disque est effectuée ou non, mais elle n'est jamais effectuée "à moitié". Cela permet de s'assurer en permanence de l'intégrité du système de fichiers. Cette atomicité ne s'effectue pas au dépend des performances grâce à un algorithme assez sophistiqué.
Au menu également les "dancing trees", qui rendent obsolètes les "B-trees" utilisés auparavant. Cette technologie permet de gérer des systèmes de fichiers d'une taille importante. Reiserfs 4 intègre maintenant un système de plugins afin de faciliter le développement de fonctionnalités supplémentaires. Toutes ces fonctionnalités permettent d'envisager de nouvelles applications, ainsi sa très grande facilité de gestion de nombreux petits fichiers lui permettrait de remplacer avantageusement une base de données dans certains cas.
Au final Reiserfs met la barre assez haut et n'a pas à rougir face à ses principaux rivaux (ext3 notamment).
NdM : merci à Dario Spagnolo et à Mark Havel pour avoir également proposé des dépêches sur le sujet.
Reiserfs est un système de fichiers journalisé, c'est à dire qu'il apporte un gain de sécurité en terme d'intégrité des données par rapport à un système de fichiers classique. Cette version a été écrite sans utiliser le code de la version précédente, qui sera toujours maintenu pour corriger les bugs le cas échéant. Les développeurs affirment avoir conçu cette nouvelle mouture en portant une attention particulière à la qualité du code.
Reiserfs supporte les transactions atomiques : une modification sur le disque est effectuée ou non, mais elle n'est jamais effectuée "à moitié". Cela permet de s'assurer en permanence de l'intégrité du système de fichiers. Cette atomicité ne s'effectue pas au dépend des performances grâce à un algorithme assez sophistiqué.
Au menu également les "dancing trees", qui rendent obsolètes les "B-trees" utilisés auparavant. Cette technologie permet de gérer des systèmes de fichiers d'une taille importante. Reiserfs 4 intègre maintenant un système de plugins afin de faciliter le développement de fonctionnalités supplémentaires. Toutes ces fonctionnalités permettent d'envisager de nouvelles applications, ainsi sa très grande facilité de gestion de nombreux petits fichiers lui permettrait de remplacer avantageusement une base de données dans certains cas.
Au final Reiserfs met la barre assez haut et n'a pas à rougir face à ses principaux rivaux (ext3 notamment).
NdM : merci à Dario Spagnolo et à Mark Havel pour avoir également proposé des dépêches sur le sujet.
Reiserfs V4 (1669 hits)
Benchmarks Reiserfs VS ext3 (2320 hits)
"dancing trees" (1196 hits)
La news sur Slashdot (1264 hits)
La news sur OSnews (667 hits)
Téléchargement (1072 hits)
> Lire la dépêche (156 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #466704.




Voir le thread "silent semantic change with reiser4" sur lkml
Pour résumer reiser4 introduit dans le fs la notion tout fichier est un répertoire (oui ds ce sens la), et ça crée pas mal de trous de sécu très grave. Donc reiser4 a été véto-isé par al viro, mainteneur du vfs, car trop crappy pour l'instant. Voir le thread sur la ml pour les "gory details".
[^]Re: Voir le thread "silent semantic change with reiser4" sur lkml
Bonjour,
A-t-il on bon lien pour résumé le fils qui est énorme, pour ceux qui n'ont pas le temps de tout lire, et qui aimeraient savoir si linux va de l'avant où reste arcbouté sur ses acquis (lire le fs du "futur": ext2 avec un patch pour le rendre journalisé: ext3; ça me rappel la comptabilité 16bits de ...).
Merci.
Bubu.
NB: svp mettre la réponse à la question ci-après, et m'envoyer directement à cette adresse ( nobody@dev.null ) les remarques consernant le fs du futur. Merci encore!