jeudi 10 avril
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | O'Reilly | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006

Posté par herodiade (). Modéré le 23 juillet 2006.
Linux
Après l'annonce d'une documentation sur les possibilités d'inclusion de Reiser4 dans le noyau Linux, l'intégration de ZFS dans une mise à jour de Solaris (début Juin), l'annonce de la séparation de WinFS et de Windows Vista (fin Juin), ou encore l'annonce il y a quelques semaines du début des travaux sur ext4, le successeur d'ext3 (voir les liens pour plus d'information sur ces questions), l'activité prospective autour des systèmes de fichiers semble d'une actualité brûlante.

C'est dans ce contexte bouillonnant qu'a eu lieu, en Juin, une rencontre des développeurs de systèmes de fichiers de Linux, afin de discuter des orientations des développements dans ce domaine pour les 5 prochaines années. Cette rencontre, le Linux File Systems Workshop 2006, qui a réuni 13 talentueux développeurs pendant 3 jours, fut organisé par Valerie Henson (développeuse de ZFS pour Intel), Zach Brown (développeur d'OCFS2 chez Oracle) et Arjan van de Ven (développeur noyau touche à tout), et sponsorisée par Intel, Google et Oracle. Quelques célébrités ont participé à cette réunion d'exception, comme Christoph Hellwig, Theodore Ts'o et Linus Torvalds.

Valerie Henson (merci à elle !) a rédigé une remarquable synthèse de ces discussions palpitantes pour le site LWN.net. Voici un résumé de son travail en français.

> Lire la dépêche (38 commentaires, moyenne: 3,4).  

Le problème

La capacité de stockage des disques durs croît très rapidement. En revanche d'autres caractéristiques importantes pour les performances, telles que la bande passante et le temps de recherche en lecture (read seek time) évoluent beaucoup moins vite.
En conséquence nous sommes peu à peu amenés à utiliser des disques contenant beaucoup de données mais dont le temps d'accès et le volume de données transférables par secondes deviennent proportionnellement ridicules. Ces deux facteurs limitant deviendront de plus en plus sensibles.
D'autre part la fiabilité des disques durs (en nombre d'erreur matérielles d'Entrées/Sorties par volume de données) ne s'améliore pas: nous devrons donc composer avec un nombre croissant d'erreurs matérielles par disque dur lorsque leur capacité et nos besoins en volume de stockage augmenteront.

Ces problèmes ont déjà des répercussions très concrètes. Par exemple le serveur principal hébergeant kernel.org a récemment souffert d'une panne RAID affectant le système de fichier. La réparation par fsck (l'outil de diagnostic et de réparation des systèmes de fichiers Unix) a pris plus d'une semaine ; à ce niveau, il aurait même été plus rapide de restaurer des sauvegardes !

Comment les divers systèmes de fichiers de Linux vont-ils appréhender ces difficultés ? Comment les outils tels qu'fsck vont-ils se comporter sur des disques devenant énormes, mais pleins d'erreurs et très lents ?

Premier jour, la réparation des systèmes de fichiers

La lenteur des outils de réparation des erreurs (fsck) est un problème important. La solution généralement suggérée consiste a optimiser ces logiciels. Cependant le travail d'optimisation a déjà été poussé très loin, surtout pour le fsck d'ext2/ext3. Il n'est pas raisonnable de penser qu'on puisse doubler ces performances tous les deux ans (alors que la taille des disques durs peut doubler dans ce laps de temps).
La solution envisagée serait d'adapter les fs (file system, système de fichiers) pour qu'ils supportent les réparations partielles et concurrentes à chaud. Il faudrait aussi que les fs sachent absorber de fréquentes erreurs d'E/S (Entrées/Sorties) sans perturber le système d'exploitation.

Premier jour, les disques durs et la gestion de leurs erreurs

Les disques durs ne retournent pas toujours des informations fiables, et dans certains cas, échouent à signaler des erreurs d'écritures au système d'exploitation.
Le récent système de fichiers ZFS, de Solaris, propose une solution élégante à ce problème en redoublant les sommes de contrôles matérielles (effectuées par les disques) par des sommes de contrôles logicielles (effectuées par le pilote du système de fichiers), ce qui permettrait d'éviter de nombreux dysfonctionnements du système en réduisant le nombre de cas où le celui-ci s'appuie sur des données corrompues sans le savoir.

D'une façon générale, les erreurs d'E/S matérielles sont très courantes, il faut donc pouvoir les gérer de façon robuste, en particulier pour les données les plus importantes, telles que les méta-données (informations complémentaires aux données, telles que les droits, propriétaires, emplacement physique etc.) du fs. Une solution fréquemment adoptée consiste à conserver de multiples copies de ces données sensibles. Mais cette solution n'est pas parfaite: il est délicat de synchroniser les copies pour qu'elles restent à jour, et la probabilité que les diverses copies soient simultanément corrompues reste finalement étonnamment élevée. Des solutions alternatives ou complémentaires seront donc étudiées.

Côté performances, il a été discuté des possibilités d'utiliser de la mémoire flash pour améliorer les performances. Mais cette option ne peut pas être universelle, et ne doit pas devenir une dépendance dure.

Premier jour, les leçons à tirer de l'expérience des systèmes de fichiers existants

La position des méta-données doit être définie par un emplacement constant plutôt que par un « nombre distinctif magique » (comme le fait ReiserFS, voir les liens), sans quoi la fiabilité de leur identification n'est pas garantie, et la fiabilité des réparations par fsck ne peut être vraiment assurée.
La question de la distinction entre les méta-données actuelles et celles des précédentes occurrences du même système de fichiers sur la même partition (par exemple après qu'on ait exécuté newfs plusieurs fois sur une partition) est délicate et doit aussi être prise en compte. Des solutions satisfaisantes ont été trouvées pour ce problème précis.

La question de l'économie des ressources a été abordée. Il apparaît qu'un système GNU/Linux typique contient souvent une grande proportion de fichiers dont la taille est inférieur à 4Ko. Or ext2 et ext3 ne fonctionnent pas de façon optimale avec les très petits fichiers. En conséquence, les développeurs ont estimé que les nouveaux systèmes de fichiers devraient être conçu pour gérer les petits fichiers de façon plus efficace.

Premier jour, revue des principaux systèmes de fichiers

Une revue des principaux fs a été conduite afin d'établir les points forts et les points faibles des expériences passées.

Les qualités de simplicité et performances de ext2 et FFS ont été relevées, mais nuancées par des défaut de ces fs tels que l'absence de protection contre la corruption des disques et la durée du fsck après un redémarrage forcé.

SoftUpdate, une amélioration de FFS maintenant implémentée dans les principaux systèmes BSD corrige le problème de temps de restauration après un arrêt intempestif mais a été jugé trop complexe à ré-implémenter pour Linux.

L'expérience des systèmes journalisés, tels qu'ext3 ou ReiserFS est jugée plutôt positive, en particulier pour la rapidité de la restauration après une panne. Mais la perfection n'est pas de ce monde, et là aussi quelques limitations sont visibles: coté performances (notamment en raison du besoin de doubler les opérations d'écriture physiques), et, là encore, l'absence de protection contre la corruption physique des disques.

Il est apparu que les systèmes de fichiers à journaux structurés (log-structured) n'ont finalement pas percés, en dépit d'un enthousiasme initial dans le monde académique. La ré-allocation des blocs en tâche de fond, nécessaire pour leur fonctionnement, est apparue comme trop complexe et coûteuse en pratique.

Les vertus de ZFS ont étés pointés, en particulier la facilité d'implémenter le support de snapshots (copies à la volée) sur ces systèmes ; mais quelques lacunes n'ont pas échappé à la sagacité des développeurs.

Deuxième jour

Le deuxième jour était dédié aux réflexions sur les problématiques d'architecture.
Les buts des réflexions devaient être orientés par les problèmes décrits plus haut, et ont été condensés dans la formule « repair-driven file system design » (conception de systèmes de fichiers orientée par la réparation), qui synthétise assez bien les diverses problématiques qui préoccupaient les développeurs (lenteur d'fsck, nombreuses erreurs disques, besoin d'augmenter la robustesse et la possibilité de réparation, ...) et tente de les placer au coeur même de la conception, et non comme une problématique à envisager dans l'après coup.

Deuxième jour, chunkfs et les « inodes de prolongement »

L'idée de chunkfs (littéralement, le « système de fichiers par morceaux ») répond aux difficultés rencontrés lors des tentatives pour améliorer le rendement de fsck sur le système ext2. Les solutions envisagées rencontrent souvent le même obstacle: lorsqu'une zone est considérée défectueuse, il faut parcourir l'ensemble du fs pour trouver et corriger toutes les répercussions possibles. Val Henson décrit en détail une de ses tentatives infructueuses échouant sur cet écueil.

C'était compter sans Arjan van de Ven, qui apporta une idée lumineuse, renversant totalement la façon d'approcher le problème !

Puisque la détection d'une panne à un emplacement donné du système de fichier impose l'analyse complète de ce système, pourquoi ne pas subdiviser un fs en une collection agglomérée de plusieurs petits fs (des chunks, morceaux) ? Ainsi les zones à analyser en cas de défaut seraient réduites à la taille totale des seuls « morceaux de fs » concernés.

Mais comment alors exploiter son fs pleinement ? Par exemple, que se passe-t-il si un fichier doit être plus gros que l'emplacement dans lequel il est créé ?
Arjan propose de faire continuer le gros fichier dans un autre « morceau de fs », et d'utiliser un inode (structure de donnée regroupant les méta-données pour un fichier ou répertoire donné) pointant vers ce nouvel emplacement (et réciproquement, de cet emplacement vers l'origine). Ainsi nous pouvons avoir des fichiers et des répertoires qui débordent de leur « morceau » initial et retrouver leur suite sur un autre « morceau ». Ce concept fut nommé, en anglais, « continuation inode » (que j'ai traduit approximativement par « inodes de prolongement »).

Outre la réduction du temps de vérification par fsck, ce système permettrait de faire de l'analyse et de la réparation à chaud: seul le « morceau » défectueux doit être rendu indisponible pour ces opération, non plus l'ensemble du système de fichier. Cela devrait aussi permettre d'apporter des réponses concrètes aux problèmes de fragmentation.

Ce nouveau concept semble avoir emporté l'enthousiasme des développeurs, gageons que de belles choses en sortiront !


Deuxième jour, doublefs

Cette idée de Theodore Ts'o et Val Henson consiste à pré-allouer deux copies des méta-données avant écriture. On écrirait la seconde copie uniquement après que la première (et les données correspondantes) soit physiquement écrite sur le disque (fsync(2)). Il est ainsi plus facile de récupérer un état consistant (avant ou après la première écriture) en cas de panne: si la première copie, écrite, est endommagée, la première est intacte et représente les méta-données à l'état précédant la panne. Comme les copies sont écrites en deux fois, on peut les placer à des endroits différents du disque, ce qui réduit le risque de les voir toutes deux endommagées par une même erreur matérielle.


Deuxième jour, méta-données des fichiers dans les entrées des répertoires

Traditionnellement, outre les données, un fichier possède des méta-données dans une inode dédiée, et dans une entrée de répertoire (directory entry).
La possibilité de placer les méta-données des fichiers dans les entrées des répertoires correspondants (plutôt que dans des inodes séparées) a été envisagée. Cela permettrait d'améliorer les performances en lecture dans certains cas, car les méta-données utiles sont alors rassemblées dans un seul endroit au lieu de deux, et réduirait la fragmentation.
Cette approche appelle des évaluations complémentaires pour décider de la bonne façon d'équilibrer les divers facteurs influençant les performances.


Deuxième jour, l'allocation des données

Comment optimiser l'allocation des blocs pour l'écriture des données sur le disque de façon à éviter la fragmentation, et sachant qu'on connaît rarement la taille des données à écrire à l'avance ?
Des idées astucieuses pour deviner la taille du fichier à écrire ont été exposées, comme le fait de deviner son ordre de grandeur à partir du nom du fichier (un fichier "*.ogg" aura généralement besoin de plusieurs Mo, tandis qu'un fichier "*.pid" sera plus probablement un fichier de quelques octets seulement). Ce type d'informations basées sur les noms de fichiers pourrait même être construite dynamiquement en établissant des statistiques à partir des données déjà écrites sur le disque ; son implémentation pourrait être partagée entre les divers fs si elle était implémentée dans la couche d'abstraction VFS.


Deuxième jour, les besoins à court terme

Certains besoins ont été identifiés comme hautement prioritaires: il faudrait que des solutions soient disponibles d'ici un an environ. Parmi ceux-ci figurent bien entendu l'accélération de la réparation des fs par fsck après une panne. Il est aussi apparu urgent de renforcer la gestion des erreurs et d'ajouter des sommes de contrôles pertinentes pour vérifier l'intégrité des méta-données dans les fs existants.
La possibilité de forcer le démontage des systèmes de fichiers -même lorsqu'ils contiennent des fichiers ouverts- sera bientôt concrétisée.
Être capable de créer un système de fichier similaire à ceux qu'on obtient après une longue utilisation (fragmentation etc.) est un besoin important, car cela permet de faire des tests de charges et optimisations plus réalistes. Des solutions sont déjà formalisées, les outils devraient suivre.


Troisième jour, les plans pour le futur

Comme le développement d'un nouveau système de fichiers prend environ 5 ans (de la conception à l'utilisation en production), les développeurs ont décidé de simultanément commencer à travailler sur de nouveaux systèmes de fichiers, et de continuer à essayer d'améliorer les fs existants pour qu'il permettent d'attendre jusque là. La plupart des idées exposées ici seront sans doute implémentées à l'état de prototype pour évaluation: chunkfs, doublefs, méta-données regroupées dans les entrées de répertoires ...
Et bien entendu, les besoins à court terme, tels que le support des démontages forcés, ont de fortes chances d'être prochainement implémentés !

Pour finir, les développeurs ont prolongé la dernière journée en buvant la bière gratuite (mais pas libre) offerte par Google et en faisant des promenades sur le tracteur d'Inaky Perez-Gonzalez. Signe que tout est sur la bonne voie !


Compléments d'information sur l'actualité prospective dans le monde des systèmes de fichiers :

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.

tout simplement l'état de l'art !

Posté par Jean-Max Reymond (page perso, ) le 23/07/2006 à 11:18. (lien). Évalué à 10.

quel plaisir de voir des réunions où tous les acteurs majeurs sont présents et coopèrent sans arrière pensée pour partager leurs connaissances, améliorer les produits et surtout affronter les défis de demain.
bravo :-)

--
CKR Solutions Open Source

Bravo !

Posté par patrick_g (page perso, ) le 23/07/2006 à 11:50. (lien). Évalué à 10.

Bravo pour cette magnifique news, très complète et très interessante. En fait j'ai bien mieux compris les idées importantes de ce sommet en lisant ce résumé en français que quand j'étais allé déchiffrer péniblement les articles de LWN....Merci donc à herodiade.

Une petite question : On assiste depuis qq années à l'annonce de l'arrivée prochaine du stockage purement sur de la RAM persistante, que ce soit de la NAND perfectionnée ayant des cycles lectures/écritures corrects ou alors la nouvelle MRAM (magnetic RAM).
Je pense que les possesseurs de laptop seront d'accord avec moi pour ne pas regretter leurs disques durs si on obtient en échange une barette de 128 Go de MRAM : un support entièrement silencieux, sans aucune partie en mouvement, très fiable, économe en énergie et doté d'une rapidité sans commune mesure !
Mais est-ce qu'il sera toujours pertinent de s'appuyer sur nos fs classiques avec ce type de stockage état solide ? Nos fs tiennent comptent des caractéristiques habituelles des disques durs (cylindres, pistes, rotation....etc) qui n'ont plus aucune importance dans ce cas.
Est-ce qu'il ne faudrait pas dès maintenant commencer l'écriture d'un SSFS (Solid State File System) tirant parti au maximum des caratéristiques très alléchantes de ces supports ?

[+] "Ce type d'informations basées sur les noms de fichiers"

Posté par Sufflope (Jabber id, page perso, ) le 23/07/2006 à 12:25. (lien). Évalué à -1.

Comme XP ?

--
Le meilleur hébergeur de forums, gratuit et sans pub !

traduction

Posté par xhub () le 23/07/2006 à 13:13. (lien). Évalué à 6.

très bon article et merci pour la traduction

j'en profite

Posté par Bactisme (page perso, ) le 23/07/2006 à 21:21. (lien). Évalué à 2.

Je cherche un projet fait par des étudiants que j'avais rencontré au village assos au linux solution 2006 à Paris.

Il developpais un système pour mettre des tags sur les fichiers, avec de l'indexation et en utilisant une base de données externe (postgres)

Je retrouve plus le nom.

C'est pas vraiment un systéme de fichier mais bon ..

(dernière allé, au milieu dans un angle d'une allé transversale)

[Typo]

Posté par FReEDoM (page perso, ) le 24/07/2006 à 00:10. (lien). Évalué à 2.

Dans le deuxième lien, il faudrait remplacer "donées" par "données"

Voilou, sinon bel article que je m'apprête à lire mais plutôt demain matin :)

:-)

Posté par devloop (page perso, ) le 24/07/2006 à 06:03. (lien). Évalué à 4.

C'est évident qu'il y a un travail à faire, en particulier pour les entreprises qui manipulent des disques à très grande capacité...
Le fait que Google développe ses propres fs le montre bien (avec leur chunk de 64 Mo :p )

L'idée de stocker les méta-données dans le dirent est intéressante. Si le nom de fichier et ses métadonnées se trouvent côte à côte dans un dirent, aurons-nous encore besoin des numéros d'inode ? :)

Pour ce qui est de l'idée de plusieurs fs dans un fs principal je suis moins enthousiasme. Qui dis fs dis superblocks... dans la pratique combien de place devra-t-on sacrifier pour nos données ?
Même avis pour le principe de copie des métadonnées... mais j'en changerais peut-être (d'avis) si un jour j'ai un gros pb de fs (ce qui n'est encore jamais arrivé :) )

J'aurais bien aimmé qu'ils se penchent aussi sur le cryptage ou la compression des données ou encore la possibilité d'éffacer simplement ses données de façon sécurisée (j'entends un fichier)

Troll sur libre/pas libre (bis)

Posté par Zenitram (page perso, ) le 24/07/2006 à 09:10. (lien). Évalué à 1.

Pour finir, les développeurs ont prolongé la dernière journée en buvant la bière gratuite (mais pas libre)

Bah... Parait qu'un produit, dès qu'il n'est pas logiciel, qu'on ne peut pas modifier/redistribuer comme on veut mais seulement consommer c'est libre, à voir le troll ici http://linuxfr.org/2006/07/17/21106.html , donc la bière offerte peut s'appeler bière libre...
Allez, un petit tour sur Jamendo.com pour y voir en grand "libre" la où on a la meme liberté que pour cette biere : consomer oui, modifier non.

Humeur

Posté par Vincent Pelletier () le 26/07/2006 à 06:56. (lien). Évalué à 2.

J'aimerai bien qu'on m'explique ce que la fragmentation a de si lumineux. Si c'est la réponse à un besoin de scalabilité, c'est vraiment pas terrible.

Pour rappel, voilà les "chunks" déjà existants :
le bit (à mon avis, on ne peut rien faire à ce niveau)
l'octet (tiens, au fait, pourquoi 8 bits ?)
le secteur (512 octets sur un disque dur, 1024 parait-il sur un cd, ...)
la tête de lecture
le cylindre
(ces deux dernières notions semblent enfin tomber en décrépitude, mais sont toujours présentes)
le bloc vu par le système de fichier (un groupe de secteurs, taille variable suivant le système de fichier)
la partition (taille variable, avec une géométrie soumise à moultes contraintes, dures ou souples, comme la nécessité de contenir un nombre entier de secteurs, de commencer au début d'un cylindre, de finir à la fin d'un cylindre,...), avec un système de partitionnement qui peut lui même définir une avalanche de blocs imbriqués, cf. les partitions étendues
le disque

Voila tout ce qu'il faut déjà connaitre pour un système d'exploitation voulant accéder à un élément unique d'information.

Ensuite, il devra probablement le stocker en mémoire, dans le bon segment et la bonne page, nécessitant pour l'accès de grouper l'adresse physique en plusieurs (2 ?) paquets à envoyer successivement pour enfin accéder à un bloc de donnée de la taille du bus mémoire, etc...

L'informatique, ce yaourt avec d'authentiques morceaux de morceaux dedans. Et avec un êtit arière-goût de gachis de cycles machine et de bande passante, qu'on oublie quand tout marche.

Bon, je vous laisse, je vais développer à coups de caractères dans des lignes dans des fichiers dans des modules dans des projets dans des...

Revenir en haut de page

Run by Team LinuxFr

Cette page a été générée par Templeet en 0.1518s (dont 0.0264 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.