Articles : Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006
Posté par herodiade (). Modéré le 23 juillet 2006.
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.
![[en]](../images/en.png)
Partie 1: Le problème (par Val Henson, pour LWN) (2027 hits)-
Partie 2: Premier jour, les données (par Val Henson, pour LWN) (873 hits)
-
Partie 3: Jours 2 et 3 (par Val Henson, pour LWN) (800 hits)
> Lire la dépêche (38 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #737554.
Run by 
Cette page a été générée par Templeet en 0.0574s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Humeur
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
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
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
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
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
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
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
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.