dimanche 05 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Le développement d'ext4 a commencé

Posté par lesensei (). Modéré le 01 juillet 2006.
0
Suite à la proposition de différents patchs pour ext3 (la dernière mouture du système de fichiers spécifique à Linux) par des développeurs du noyau, une discussion a eu lieu sur la LKML entre ceux en faveur de changement mettant potentiellement à mal la stabilité du noyau et ceux qui préféreraient aller de l'avant, laissant les problèmes de stabilité aux distributeurs (rappelons que ceci est officiellement la nouvelle politique du noyau, bien que les développeurs évitent bien sûr autant que possible de tout casser).
Étant donné la base d'utilisateurs d'ext3, les inquiétudes portant sur la stabilité du code et du format sur disque après intégration de patchs importants ont été nombreuses, et Linus y a été particulièrement sensible (étant donné qu'un système de fichier instable mettrait en péril le travail des développeurs qui l'aident, on peut le comprendre).
Il a donc été décidé d'ajouter un système de fichier ext4 dans le code du noyau, et de faire les changements dangereux sur celui-ci. La stabilisation du code est prévu dans environ 12 à 18 mois, bien que de nombreuses améliorations seront probablement proposées.
L'article qui suit est une traduction complète du mail de Théodore Ts'o (mainteneur, avec d'autres, d'ext2/3) détaillant le mode de développement prévu pour ext4.

NdM Merci a patrick_g de nous avoir proposé une dépèche sur le même sujet.

> Lire la suite (43 commentaires, moyenne: 3,3).   [dépêche : 6263 caractères]

Étant donnée la récente discussion sur la LKML il y a deux semaines, il est clair que de nombreuses personnes s'intéressent aux plans futurs de développement du système de fichiers ext2/ext3, étant donné qu'il est un des systèmes de fichiers plus populaires et les plus couramment utilisés, en particulier parmi la communauté des développeurs du noyau.
Pour cette raison, les intérêts qui lui sont portés sont plus importants qu'ils ne le seraient pour d'autres systèmes de fichiers. Les inquiétudes exprimées peuvent se résumer aux points suivants:

* Stabilité. Une des inquiétudes soulevées est que durant l'ajout de nouvelles fonctionnalités, des erreurs de programmation puisse causer la perte du travail des développeurs. C'est particulièrement problématique étant donné que le noyau 2.6 est un noyau de série "stable", mais traditionnellement les développeurs ext2/3 ont été très attentifs même lorsqu'ils travaillaient sur les séries de développement car les développeurs du noyau ont tendance à ne pas apprécier lorsque leur système de fichiers est corrompu.

* Confusion autour de la compatibilité. Bien que le "superblock" de ext2/3 soit très flexible et puissant au regard de l'indication de compatibilité ascendante et descendante, la possibilité de confusion des utilisateurs a provoqué l'inquiétude de certains, au point qu'il ait été proposé de volontairement casser la compatibilité descendante afin de supprimer tout doute possible quant à la compatibilité ascendante. Cela serait aller trop loin, bien que nous n'ayons pas besoin de mettre en garde contre du code au niveau noyau ou distribution qui mettrait sans avertissement préliminaire à jour le système de fichiers d'un utilisateur, l'empêchant de monter celui-ci sur de plus vieux systèmes. Une confirmation de l'utilisateur doit être obtenue, de préférence par un outil qui permettra une mise-à-jour ou une remise à l'ancienne version avec facilité.

* Complexité du code. Le troisième sujet d'inquiétude est que si le code n'est pas correctement factorisé, il pourrait devenir difficile à lire à cause des nombreuses conditions utilisées pour supporter les formats de système de fichiers plus anciens.

Malheureusement, ces différents sujets étaient parfois mélangés les uns aux autres dans la discussion d'il y a deux mois, et il était par conséquent difficile de progresser.
Les inquiétudes de Linus semblent avoir porté principalement sur le premier point, avec peut-être une faible considération du troisième. D'autres se sont particulièrement préoccupés du second.

Pour répondre à ces préoccupations, après en avoir discuter entre nous, les développeurs ext2/3 voudraient proposer de suivre le chemin suivant.

1) La création d'un nouveau système de fichiers dans l'arbre des sources du noyau 2.6 dans /usr/src/linux/fs/ext4 qui se présentera d'abord comme le système de fichiers "ext3dev". Il sera marqué explicitement comme CONFIG_EXPERIMENTAL [NdT: tag des fonctionnalités expérimentales lors de la configuration d'un noyau Linux avant sa compilation], et sera en réalité un fork de développement d'ext3. Une séparation similaire aura lieu pour fs/jbd [NdT: le code du journal utilisé par ext3] afin de supporter un jbd 64-bits, qui sera utilisé par fs/ext4 et les versions futures d'ocfs2 [NdT: le système de fichier pour clusters d'Oracle].
2) Les corrections d'erreurs de programmation du point de vue de la propreté du code 32-bits et des problèmes de sécurité/de oops iront dans fs/ext3, mais tous les nouveaux développements iront dans fs/ext4.
Il y a un quelques incertitudes encore quant au fait que les fonctionnalités peu risquées telles que la réduction de l'emprunte mémoire de la structure de extX, et des allocations retardées pour ext3, qui n'ont pas d'impact sur le format, devraient aller dans fs/ext3, ou si de telles améliorations devraient être réservées aux utilisateurs de fs/ext4. Ceci est un compromis coût/bénéfice pour lequel la communauté de la LKML devra décider si les pertes en stabilité du code valent les améliorations pour les utilisateurs actuels de ext3, étant donné l'existence de la branche de développement.
De plus, nous supposons que différents changements impliquant des modifications du format, telles que le support d'horloges plus précises, ne vont _pas_ être intégrées dans le code de fs/ext3, et que les gens qui veulent ces fonctionnalités devront utiliser le code stable/de développement de fs/ext4.

3) Le code de ext4 continuera de monter les systèmes de fichiers plus anciens en ext3, puisqu'il est nécessaire de s'assurer une mise-à-niveau sans accroc pour les utilisateurs depuis ext3 vers ext4. De plus, une fois une fonctionnalité ajoutée au système de fichier ext3dev, un gros effort sera fourni afin de continuer de supporter les améliorations du format du système de fichier vers l'avant, exactement comme nous le faisons avec l'ABI syscall. (Des urgences peuvent avoir lieu si nous faisons une grave erreur et que nous nous mettons le dos au mur; mais exactement comme nous le faisons pour les changements dans l'ABI noyau/espace utilisateur, s'il est question de savoir si oui ou non un format de système de fichiers particulier peut être supporté tout en continuant sans cesse d'aller de l'avant, nous ne validerons les changements dans le code principal du noyau qu'une fois en confiance sur ce point.)

4) À un moment donné, probablement dans 6-9 mois quand nous serons satisfaits de l'ensemble des fonctionnalités qui auront été ajoutées à fs/ext4, et que nous aurons confiance dans la stabilité du format du système de fichiers, nous soumettrons un patch qui fera que fs/ext4 se présentera comme le système de fichiers ext4. L'implémentation nécessitera peut-être encore quelques vérifications avant que nous soyons aussi confiants dans sa stabilité que dans celle d'ext3 actuellement. À ce moment, peut-être dans 12-18 mois, nous demanderons éventuellement que le code dans fs/ext3/* soit supprimé et que fs/ext4 se présente comme supportant le système de fichiers ext3 également.
Nous croyons que ceci devrait répondre à la majorité des inquiétudes qui ont été soulevées, en particulier celles de Linus et Jeff. Les commentaires sont évidemment les bienvenus.

- Ted

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

compatibilité ?

Posté par briaeros007 () le 01/07/2006 à 13:07. (lien). Évalué à 3.

Ne serait t'il pas plus simple d'essayer de faire un systeme comme partition magic qui permet de convertir des partitions d'un type en un autre type, tout en conservant les données et de considérer la compatibilité descendante/ascendante comme réglé par ce problème ?
Cela permettrait d'avoir a éviter de réinventer la roue a chaque fois quand on vois qu'il peut y avoir des initiatives interessantes comme reiser4 (qui pompe malheureseusement actuellement énormément de cpu sur un dd fragmenté pour l'écriture de gros fichiers :( (en tout cas chez moi) ) ou zfs.

--
Subete ga wakatta toki…watashi ga anta wo korosu.

lwn

Posté par Matthieu C () le 01/07/2006 à 13:14. (lien). Évalué à 5.

lwn proposait un article assez complet sur ext3 et le pourquoi de partir sur ext4 : http://lwn.net/Articles/186754/

GFS, drbd, cluster

Posté par Christophe Merlet (page perso, ) le 01/07/2006 à 14:24. (lien). Évalué à 3.

Ce qu'il manque le plus à Linux concernant les systèmes de fichiers, c'est l'intégration de système de fichiers clustérisé tel que GFS, Lustre, GPFS, PVFS.

Il y a bien OCFS qui a récemment intégré le kernel, mais comme son nom l'indique il est plus destiné aux bases de données. Il n'y a rien à l'heure actuel pour les cluster de calculs hautes performances.

L'autre importance d'avoir un système de fichiers clustérisé et de pouvoir faire du raid réseau avec drbd en configuration actif-actif. Là encore rien n'est intégré en standard dans le tronc commun.

Résultat, lorsque l'on cherche de la haute performance et de la haute disponibilité on est obligé de jongler avec les compromis ou avec du matériel hors de prix :(

ext4 ne me parait pas être la priorité du moment, ext3 étant quand même le plus performant des systèmes de fichiers existant (ce n'est pas un troll, j'ai des benchs mais les résultats ne sont pas un modèle de clarté :o) http://redfox.redfoxcenter.org/benchs/ ).

content-type dans le filesystem

Posté par Mildred (Jabber id, page perso, ) le 01/07/2006 à 18:09. (lien). Évalué à 4.

Une question, pourquoi est-ce que le type des fichiers n'est pas stoké dans le filesystem à coté des permissions ou de ces choses là. Cela simplifirait quand même.
Fini les extensions, fini la détection de type parfois foireuse ...

--
La Roue du Temps

Politique de développement du noyau.

Posté par neologix (page perso, ) le 02/07/2006 à 10:43. (lien). Évalué à 4.

Salut.

laissant les problèmes de stabilité aux distributeurs (rappelons que ceci est officiellement la nouvelle politique du noyau, bien que les développeurs évitent bien sûr autant que possible de tout casser).


Il n'y a que moi que ça choque?

En passant, certains d'entre vous compte-t-ils utiliser la branche 2.6.16.y (http://kerneltrap.org/node/6386) ? Parce que si cette politique est effectivement la politique officielle, pour une machine en production, on n'aura plus le choix

Pourquoi pas Reiser4 ?

Posté par Pierre Jarillon (page perso, ) le 03/07/2006 à 10:40. (lien). Évalué à 2.

Pourquoi ne pas utiliser Reiser4 http://www.namesys.com/ qui est un FS vraiment nouveau, innovant et extrèmement performant ?
J'ai vraiment l'impression qu'il s'agit du syndrome NIH (not invented here) qui vient encore de frapper.

Nouveautés

Posté par Maxime (Jabber id, page perso, ) le 04/07/2006 à 02:25. (lien). Évalué à 1.

Qu'en est t'il exactement des nouveautés qui seront apportées par cette version ?

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1689s (dont 0.0232 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !