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) (2020 hits)-
Partie 2: Premier jour, les données (par Val Henson, pour LWN) (870 hits)
-
Partie 3: Jours 2 et 3 (par Val Henson, pour LWN) (796 hits)
> Lire la dépêche (38 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #736898.
Run by 
Cette page a été générée par Templeet en 0.0523s (dont 0.0056 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Bravo !
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 !
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 !
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 !
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 !
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 !
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.