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

Posté par . Modéré par Jaimé Ragnagna.
Tags : aucun
0
23
juil.
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. 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 :
  • # tout simplement l'état de l'art !

    Posté par (page perso) . É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 :-)
  • # Bravo !

    Posté par (page perso) . É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 ?
    • [^] # Re: Bravo !

      Posté par . Évalué à  10 .

      j'ai bien mieux compris les idées importantes de ce sommet en lisant ce résumé

      Bah, c'est normal, pour résumer il fallait aller à l'essentiel et synthétiser les détails techniques du texte d'origine ;) En tout cas, merci pour ton encouragement, ça fait plaisir.

      J'en profite pour corriger une erreur d'étourderie qui m'a échappée dans la section sur doublefs: « si la première copie, écrite, est endommagée, la première est intacte ». Il faut bien entendu comprendre « la deuxième est intacte » (ou inventer schrödingerfs). Désolé !

      Nos fs tiennent comptent des caractéristiques habituelles des disques durs (cylindres, pistes, rotation....etc) qui n'ont plus aucune importance dans ce cas.

      Linux dispose d'un certain nombre de systèmes de fichiers spécifiquement adaptés aux médias tels que la RAM, l'EEPROM etc., comme ramfs, cramfs, tmpfs et surtout jffs2 (http://sources.redhat.com/jffs2/jffs2-html/jffs2-html.html ), mais il ne conviennent pas toujours à un usage généraliste.
      Je ne sait pas si JFFS2 est vraiment adapté à la MRAM, que j'ai découvert juste à l'instant, en lisant ton commentaire.
      L'accès aux médias physiques est généralement délégué à la couche VFS et aux couche sous-jacentes (SCSI, SATA, ...) mais il faut reconnaître que les FS ne sont pas pour autant totalement dénués de « partis pris » (tendance à privilégier les accès contigus, assomptions sur les caches en mémoire, gestion spéciale des écritures sur les mémoires Flash, ...)
      • [^] # Re: Bravo !

        Posté par (page perso) . Évalué à  10 .

        Quand on propose un dépêche d'une telle qualité, il ne faut pas être surpris qu'elle passe illico en première page !
        Refais-nous de temps en temps un article comme celui-là; c'est le bonheur pour ceux qui essaient de comprendre l'évolution des logiciels libres.
        Bravo et merci !
      • [^] # Re: Bravo !

        Posté par . Évalué à  2 .

        J'ai appris en lisant le rapport de corbet sur le même site (mais en version souscripteur, accessible la semaine prochaine) sur le kernel summit que jffs2 n'était pas prévu pour gérer de grosses quantité de mémoire.

        Il est donc quaisment certain qu'il faudrait réécrire un nouveau fs exprès.

        Il y est aussi fait remarquer qu'il y a des presions sur le sujet par le projet OLPC (one laptop per child).
    • [^] # Re: Bravo !

      Posté par . Évalué à  6 .

      Oui enfin pour le moment, FreeScale va *commencer* a vendre des MRAM de 4-Mbit (pas octet hein, bit) à 25 $ pièce:
      http://eetimes.com/news/latest/showArticle.jhtml?articleID=1(...)

      Donc si tu fait le calcul, les 128 Go de MRAM, ça fait 6.5 millions de dollar..

      Mais oui, on peut espérer que le futur appartienne à la MRAM: avec un temps d'accès de 35ns, un nombre de réécriture quasi-illimité, ça fait saliver..
    • [^] # Re: Bravo !

      Posté par . Évalué à  10 .

      Concernant les systèmes de fichiers adaptés aux mémoires non volatiles; la réponse n'est pas simple.

      Tous les supports ne sont pas égaux. La mémoire Flash doit être effacé et écrite par blocs, il vaut éviter de fatiguer prématurément certaines cellules en les modifiant en permanence. Comme pratiquement tous les appareils travaillent en FAT qui demande une ré-écriture continuelle de ces secteurs, les fabriquants ont carrément intégré dans les controleurs un mécanisme d'indirection pour faire une rotation des cellules.

      Pour la MRAM, on ne connait pas encore très bien ses limites, ou en tout cas elles ne sont pas publiques. Il y a des FS adaptés à la Flash, qui ont été cité. Si la MRAM ne souffre pas de ces limitations, alors ils ne seront probablement pas adaptés. Un autre facteur a prendre en compte est la garantie d'atomicité des écritures; que se passe-t'il lorsqu'il y a une coupure au milieu d'une écriture ? Si l'écriture est faite octet par octet, ça va compliquer les choses, on va avoir beaucoup de mal à retrouver où est-ce que l'on s'est arreté, si c'est par secteur de 512 octets, c'est comme un disque ordinaire...

      Les FS classiques ne sont plus vraiment optimisés pour la géométrie des disques. Aujourd'hui je ne pense pas que l'on fabrique encore de disques qui publient leur géométrie réelle; on tombe toujours sur une géométrie logique qui permet de booter, ensuite le FS se base sur une couche d'abstraction qui fonctionne en blocs logiques.Les FS n'ont donc pas spécialement de contre indication pour leur usage sur de la MRAM.
  • # "Ce type d'informations basées sur les noms de fichiers"

    Posté par (page perso) . Évalué à  -1 .

    Comme XP ?
  • # traduction

    Posté par . Évalué à  6 .

    très bon article et merci pour la traduction
  • # j'en profite

    Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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)
    • [^] # Re: :-)

      Posté par (page perso) . Évalué à  7 .

      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 ?

      Ce principe a été pensé pour répondre à des problématiques portant sur des disques de très grande taille, pas forcément courant aujourd'hui, mais qui vont se répandre rapidement. On commence à voir apparaître pour le grand publique, à des prix raisonnables (hum), des disque d'un demi To.

      D'ici peu de temps, on va donc assister a un nouveau changement d'echelle, où il sera courant de disposer, pour son ordinateur personnel, de disques de l'ordre de grandeur du tera octet. Il est évident que dans ces conditions, tu te fiches de perdre quelques dizaines (ou même centaine) de mega octets, si en contre partie tu peux réparer ton fs (respectivement écrire|accèder aux données) en 10 fois moins de temps).

      Bref, tout ça pour dire que les stratégies et tactiques valables avec un disque de 100 Mo ne le sont pas forcément avec un disque d'un téra, et inversement.

      ndr : après relecture, mon message est quand même un tissu d'évidences...
  • # Troll sur libre/pas libre (bis)

    Posté par (page perso) . É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 . É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...
    • [^] # Re: Humeur

      Posté par . Évalué à  4 .

      Je pense que tu n'as pas saisi l'enjeu, pourtant expliqué de façon remarquable dans cet article de Val Henson, de la subdivision d'un disque. Tu parles de octets/secteur etc... mais l'approche est plus ici orientée sur la structure logique du système de fichiers : répertoires / fichiers.

      le problème :
      1) La taille du disque augmente énormément, alors que la bande passante, et les temps d'accès stagnent
      2) les problèmes d'erreurs et de corruption de disque nécessitent actuellement de scruter une bonne partie du système de fichiers pour reconstruction, et les algorithmes peuvent difficilement être "optimisés" pour compenser le (1)

      la problématique :
      - Comment organiser un système de fichiers de telle façon qu'une "reconstruction" soit la moins pénible possible.

      une idée le "Chunkfs" (pas forcément bonne, hein !) :
      - Essayer de subdiviser le système de fichiers de telle sorte que si une subdivision soit corrompue, on n'ait qu'a s'occuper de cette subdivision là pour "reconstruire" et non pas des autres parties du disque.
      • [^] # Re: Humeur

        Posté par (page perso) . Évalué à  2 .

        En lisant ce commentaire, il me vient à l'idée qu'un système à partitions logiques LVM : http://linuxfr.org/2002/10/29/10141.html est proche du besoin. Il serait juste nécessaire de le rendre dynamique afin de s'adapter à la demande.
        • [^] # Re: Humeur

          Posté par . Évalué à  1 .

          En fait LVM à mon avis ne correspond pas au besoin. un fs sur du "matériel logique" qui peut se répartir sur plusieurs disques réels.
          LVM c'est pour la [i]souplesse[/i], tu répartis tes fs/swaps/etc. (ya autre chose?) comme tu veux sur tes disques physiques, et tu peux même tout changer quand ça te plaît.
          chunkfs c'est pour la [i]robustesse[/i], le fs apparent est découpé en entités autonomes. En casser une ne casse pas tout et en réparer une n'exige pas de démonter tout le fs.

          Pour enfoncer le clou : on peut bien sûr utiliser les deux en même temps, créer des chunfs (constitué de plusieurs ext3/4/reiser/machinfs un peu modifiés) sur une partition crée en LVM.

          Gardons en tête que chunkfs est un [i]proposition[/i] même pas implémentée (et peut ête ne le sera-t-elle jamais vraiment) qui répond à UN problème (qui d'ailleurs est bien décrit dans les liens, il faut les lire) : le fait que les tailles des disques augmente [i]beaucoup[/i] plus vite que 1. les temps d'accès (et aussi les vitesses de transfert mais ici c'est pas important) et 2. la vitesse des algos de fsck (qu'il ne prévoient pas de pouvoir augmenter d'un facteur 100), avec pour conséquence des temps de fsck de plusieurs centaines d'heures à [i]court terme[/i].

          Est-ce qu'on peut leur reprocher de s'interroger sur ce problème? Je ne pense pas, parce que d'auters projets continuent (reiser4/ext3dev/gfs/fuse...) qui s'attachent chacun à un problème différent.

          Comme il a été dit lors du kernel summit, VFS a été quasi stable pendant plusieurs années. Maturité? En tout cas chaque projet travaille de son côté, mais les apports de chacun peut être carrément la prochaine évolution du vfs, profitant à tout le monde.
        • [^] # Re: Humeur

          Posté par . Évalué à  4 .

          Ce n'est pas la même couche : LVM crée des partitions, chaque partition a son fs, chaque fs a ses chunks.
          Avec LVM, le fs ne sait pas que sa partition est virtuelle et qu'il s'étend sur plusieurs disques. Et le fsck ne se fait pas sur la partition mais sur le fs.

          Ce qui serait plus proche dans l'idée c'est unionfs/squashfs/... : un fs réalisé au dessus de plusieurs autres, un fs qui les combine.
          Dans le cas actuel, on a un fs en lecture seule et un fs pour noter les modifications.
          Et avec chunkfs, on n'a pas besoin qu'un chunk soit un fs à part entière (= montable isolément). D'ailleurs, le nom est mal choisi : chunkfs n'est pas un fs, c'est une technique à intégrer dans un fs.

          Sans chunkfs, le fs prend la partition entière et place ses données dans tout l'espace. Avec chunkfs, le fs divise son espace en zones (chunks) et essaie d'y placer ses données intelligemment. Le seul avantage de ces zones, c'est qu'un fsck pourrait s'y limiter, sinon ce ne sont que des inconvénients (fragmentation, couche supplémentaire...).
      • [^] # Re: Humeur

        Posté par . Évalué à  1 .

        Il me semble que tu n'as pas saisi le pourquoi de mon commentaire :) .
        Je l'ai titré "humeur", ce qui selon moi veut dire qu'il s'agit d'un sentiment global face à un sujet.

        Une analyse avec "état de l'art" des systèmes de fichiers me semble tout à fait nécessaire. Mais pour moi il manque (mais je n'ai pas assisté ni lu quoi que ce soit hormis cet - excelent - article sur cette réunion) quelque chose de fondamental : la définition des éléments nécessaires à manipuler pour pouvoir utiliser des périphériques de stockage.

        Pour moi, ils se limitent strictement à :
        -volume : représente une suite de disques ayant un point commun (appartenir à un même groupe défini par raid/lvm/...)
        -disque : une suite finie de secteurs (malheureusement on ne peut pas descendre plus bas que le secteur, et on ne peut rien changer à ce niveau puisqu'un disque est physique - oui, ça surprend comme affirmation :) )
        -fichier : regroupement de données ayant un point commun (appartenir à un même groupe défini par le fichier)

        Donc, quelle est la différence entre une partition et un fichier ?
        Quelle est la différence entre un système de partitionnement et un système de fichiers ?
        Quelle est la différence entre un groupe de disques et un fichier ?

        Bien entendu je ne parle pas des limitations que l'on doit aux implémentations actuelles, mais sur le principe de fonctionnement.

        Pour moi il n'est pas bon d'ajouter "encore un niveau", mais plutôt d'unifier les niveaux existants, et on en sortira avec un système potentiellement récursif - donc scalable - restant facile à parcourir de par sont homogénéité en restant configurable : utiliser un groupe de disques comme un seul fichier, ou un disque comme une arborescence de morceaux indépendants inclus les uns dans les autres sur un disque.

        Mais bon, quand bien même ça se trouverai être une bonne idée, quand bien même quelqu'un l'implémenterai, qui veut d'un système "révolutionnaire" quand le système habituel "marche". (clin d'oeil à hurd, et je --->[] )
        • [^] # Re: Humeur

          Posté par . Évalué à  2 .

          Le fait est qu'ils tiennent à rester sur une base UNIXienne (j'en veux pour preuve la discussion sur les liens matériels) ce qui d'une certaine façon court-circuite tout ça (peut être est-ce dommage, je ne sais pas...)

          À mon avis, ils sont juste en train de réfléchir à la prochaine phase d'évolution du VFS, par l'ajout de nouvelles notions, pas à une refonte totale du VFS (souviens toi : Linux is evolution (C Greg KH) ; )

          Et pourtant je ne pense pas que ce soit par frilosité, vas voir les 3 (?) derniers articles de Val Henson sur lwn partie kernel (ils sont en libre accès maintenant)
        • [^] # Re: Humeur

          Posté par . Évalué à  3 .

          Ton point de vue et le leur n'ont pas le même but. Ce dont tu parles c'est repenser la manière de stocker des données alors qu'eux veulent des réponses concrètes à des problèmes présents. C'est intéressant de "révolutionner" un domaine mais ca demande beaucoup de temps. Repenser le stockage de l'information est un problème très complexe autant au niveau conceptuel que pratique et beaucoups de gens s'acharnent dessus. En attendant aujourd'hui il y a des problèmes concrets et si mon fs va mal, j'aimerais avoir des outils fiables et efficaces. La comparaison avec le hurd est bien vu, j'aodre les idées du Hurd et quand le hurd sera prêt pour le desktop je laisserais sans doute tomber linux mais pour l'instant j'utilise linux parce que ca marche et je suis bien content que les développeurs bossent sur les problèmes de maintenant pour que ca continue a marcher.

          Si tu veux des révolutions, rejoints les développeurs du Hurd ou un autre projets expérimental, chacun d'eux sera hereux de t'acceuillir. Tu y trouvera certainement ton bonheur.

Suivre le flux des commentaires

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