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 :
- L'annonce du travail sur ext4, le successeur d'ext3 (anglais)
- Linuxfr: Pourquoi Reiser4 n'est toujours pas intégré à Linux (français)
- Quelques problèmes intéressants de ReiserFS (dont la question de l'emplacement des métadonnées), pointés par Theodore Ts'o (anglais)
- WinFS dans Wikipedia (français)
- ZFS dans Wikipedia (français)
# tout simplement l'état de l'art !
Posté par Jean-Max Reymond (site web personnel) . Évalué à 10.
bravo :-)
# Bravo !
Posté par patrick_g (site web personnel) . Évalué à 10.
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 herodiade . Évalué à 10.
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 Pierre Jarillon (site web personnel) . Évalué à 10.
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 mickabouille . Évalué à 2.
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 reno . Évalué à 6.
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 Sébastien Koechlin . Évalué à 10.
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 Sufflope (site web personnel) . Évalué à -1.
[^] # Re: "Ce type d'informations basées sur les noms de fichiers"
Posté par Raphaël G. (site web personnel) . Évalué à 2.
C'est une idée générale je pense, je ne pas allouer 15Go pour /etc,/var/run par exemple ;)
Qui vont contenir des fichiers négligeables contrairement a ~/Musique et ~/Vidéo ...
Bon je me base sur une mandriva qui ont choisi de faire une petite révolution dans le home de leur utilisateur pour éviter que ça deviennent un foutoir sans nom.
Mon avis : Au début, j'ai détesté, surtout que les noms de répertoires étaient en anglais (corrigé depuis au moins dans la cooker), mais en regardant le résultat final c'est pas plus mal, mon home est maintenant correctement rangé et c'est très agréable...
[^] # Re: "Ce type d'informations basées sur les noms de fichiers"
Posté par Charles-Victor DUCOLLET . Évalué à -9.
[^] # Re: "Ce type d'informations basées sur les noms de fichiers"
Posté par benja . Évalué à 4.
[^] # Re: "Ce type d'informations basées sur les noms de fichiers"
Posté par Agalaz . Évalué à 2.
Uhuh.
[^] # Re: "Ce type d'informations basées sur les noms de fichiers"
Posté par BAud (site web personnel) . Évalué à 7.
[^] # Re: "Ce type d'informations basées sur les noms de fichiers"
Posté par Charles-Victor DUCOLLET . Évalué à 0.
# traduction
Posté par xhub . Évalué à 6.
[^] # Re: traduction
Posté par xenon_hs (site web personnel) . Évalué à 3.
[^] # Re: traduction
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à -1.
Ce soir, les g**ks dormiront moins c*n grâce à toi! Hihi
encore merci pour cet excellent travail !
Alexandre COLLIGNON
# j'en profite
Posté par Bactisme (site web personnel) . Évalué à 2.
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)
[^] # Re: j'en profite
Posté par chl (site web personnel) . Évalué à 4.
[^] # Re: j'en profite
Posté par Julien Furgerot . Évalué à 3.
[^] # Re: j'en profite
Posté par Jean-François Wauthy . Évalué à 2.
[^] # Re: j'en profite
Posté par Manuel Menal . Évalué à 6.
# [Typo]
Posté par FReEDoM (site web personnel) . Évalué à 2.
Voilou, sinon bel article que je m'apprête à lire mais plutôt demain matin :)
# :-)
Posté par devloop (site web personnel) . Évalué à 4.
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 Fanf (site web personnel) . Évalué à 7.
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 Zenitram (site web personnel) . Évalué à 1.
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.
[^] # Re: Troll sur libre/pas libre (bis)
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: Troll sur libre/pas libre (bis)
Posté par soulflyb (Mastodon) . Évalué à 3.
[^] # Re: Troll sur libre/pas libre (bis)
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Si tu as une bière gratuite à l'entrée, c'est gratuit, mais tu ne peux pas te servir librement pour autant ;-).
[^] # Re: Troll sur libre/pas libre (bis)
Posté par Zenitram (site web personnel) . Évalué à 2.
Mais bon, l'open-bar, c'est comme les CC qui sont libres, parfois l'open-bar c'est payant de chez payant, ca attire juste le chalant avec un verre gratuit avec une entrée payante...
# Humeur
Posté par Vincent Pelletier . Évalué à 2.
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 let antibarbie = xp <- xp - 1 . Évalué à 4.
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 Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Humeur
Posté par mickabouille . Évalué à 1.
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 Sylvain Sauvage . Évalué à 4.
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 Vincent Pelletier . Évalué à 1.
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 mickabouille . Évalué à 2.
À 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 GTof . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.