Amaury Bouchard a écrit 63 commentaires

Oui, c'est évidemment une question que nous nous sommes posé durant la conception de FineFS. Mais cela reste un choix pleinement assumé.

S'il fallait résumer les buts de FineFS, on pourrait les simplifier à seulement 2 points : être rapide en lecture, et garder un code le plus simple possible.

Gérer le nombre de recopies d'un fichier complexifie les choses de manière exponentielle. Non seulement il faut savoir où est présent un fichier, mais il faut être capable de gérer les réplications supplémentaires quand une machine tombe.

Encore une fois, FineFS ne se destine pas à recopier à l'identique des concepts déjà développés dans d'autres systèmes. Il y a des cas où il vaudra mieux utiliser GlusterFS, Lustre, Peerfuse, ChironFS, Coda, Ceph, ZFS, ... Ce ne sont pas les solutions qui manquent.
Notre problématique est de réduire au maximum les latences d'accès aux fichiers. Cela veut donc dire qu'il faut réduire les lectures sur le réseau. On ne peut pas se contenter de réduire les écritures réseau, car le résultat direct est une augmentation des lectures réseau.

Nos axes d'amélioration passent d'ailleurs plutôt sur la mise en place de noeuds ayant un cache qui ne contient qu'une partie des données du cluster. Mais là aussi, cela a un coût : il faut compter le nombre d'accès à chaque fichier, pour savoir lesquels on peut effacer quand on commence à manquer de place en cache pour ajouter un nouveau fichier. On peut se dire que c'est un calcul insignifiant, mais c'est pourtant impactant vis-à-vis de nos objectifs de performance.

On peut aussi faire un calcul très simple (peut-être un peu simpliste, mais bref). Imaginons un cluster de 9 machines. On ajoute un nouveau fichier sur le cluster.
En écriture :
- FineFS : Le fichier sera copié de la 1ère machine à la 2ème, puis de la 2ème à la 3ème, et ainsi de suite. (total : 9 copies réseau)
- Ta proposition : Le fichier sera copié sur 3 machines. (total : 3 copies réseau)
En lecture :
- FineFS : Lecture en local. C'est simple et rapide, quelque soit le nombre de lectures sur le fichier.
- Ta proposition : Il y a 1 chance sur 3 que le fichier soit présent en local. Si on fait 2 lectures du fichier, on a 1 chance sur 9 de l'avoir en local. Avec 3 lectures on passe à 1 chance sur 27 en moyenne.

Si on se dit que le rapport moyen est effectivement de 3 lectures pour une écriture (et sincèrement, sur du Web, il y a beaucoup plus de lectures pour une écriture), ça nous donne :
- FineFS : 9 copies réseau + 3 lectures locales.
- Ta proposition : 3 copies réseau (initiales) + 26 copies réseau (au moment des lectures) + 1 lecture locale.

Je sais bien qu'il est impensable de mettre en place ce genre d'architecture sans penser à utiliser un cache local. Le calcul complet fait intervenir la taille moyenne d'un fichier et la taille moyenne des caches sur chaque machine. Mais je voulais pointer du doigt que toute solution technique a forcément des inconvénients. Les choix de conception de FineFS ont été murement réfléchis.

Enfin, tu donnes l'exemple d'un fichier qui pourrait contenir des informations de session. Il y a vraiment des gens qui stockent leurs données de session dans des fichiers ? Une base de données me semble plus indiquée. Mais même en imaginant qu'on veuille utiliser FineFS pour cela, on aurait intérêt à utiliser les méta-données associées aux fichiers ; ainsi, ces informations seraient disponibles très rapidement sur les noeuds du cluster.

Ta suggestion était 'Vous devriez laisser la possibilité de désactiver la réplication asynchrone'.

Donc oui, en plus simple, si on désactive la réplication, on perd possiblement la réplication ;-)

En fait, en désactivant la réplication asynchrone, on ne repose plus que sur les demandes de fichiers pour répliquer les données. Par exemple, disons que le serveur A contient le fichier X ; si le serveur B a besoin du fichier X, il va le réclamer à A. Mais si A tombe en panne avant que B n'ait eu besoin du fichier, et qu'on avait désactivé la réplication qui aurait copié automatiquement le fichier de A vers B, ce fichier est perdu. Ce n'est pas une bonne idée.

Nous avons effectivement fait le choix d'optimiser les lectures, ce qui tient debout pour des applications web. Il faut voir que sur la plupart des architectures Web, c'est le trafic externe qui coûte, pas le trafic interne.

Il est complètement illusoire de faire un système qui fonctionne à la perfection aussi bien en écriture qu'en lecture, sur des petits fichiers comme sur des gros ensembles de données, qui soit à la fois distribué et réparti, avec une charge CPU proche du zéro, une consommation réseau pratiquement nulle,et une latence inférieure à celle d'un disque SSD.

Désactiver la réplication asynchrone n'est absolument pas à l'ordre du jour. Cela permettrait juste de réduire une partie du trafic réseau, mais on risquerait la perte de données. Non, cela va complètement à l'encontre des buts de FineFS.

Ce serait comme demander au GoogleFS (je parle du filesystem utilisé en interne dans les datacenters de Google, pas du montage de GMail) d'être efficace sur des petits fichiers, alors qu'il a été conçu pour des fichiers pesant des centaines de mégas voire des gigas. Ou de demander à la base Dynamo d'Amazon de gérer les données de manière relationnelle, alors que son but est justement de ne pas être relationnel pour gagner en performance.

OK, je vois ce que tu veux dire.

En fait, FineFS est à la fois (plus ou moins) synchrone et (totalement) asynchrone. C'est bien expliqué sur le site du projet. Lorsqu'un fichier est créé, ou mis à jour, la nouvelle version du fichier est immédiatement disponible en local ; c'est assez logique.
Là où ça se complique, c'est sur les autres machines du cluster. Mais FineFS repose sur un découpage en 2 étapes. Je m'explique.

Quand un fichier est mis à jour, une information est envoyée au serveur suivant du cluster, qui la transmet au serveur suivant, qui la transmet au serveur suivant, etc. Cette information fait très vite le tour du cluster (c'est un paquet de moins de 150 octets en moyenne). Dès qu'un noeud reçoit cette information, il met à jour sa connaissance du fichier, et efface sa version locale du fichier binaire.

En fait, lorsque quelqu'un réclame le fichier sur un serveur (autre que le serveur d'origine qui a reçu la nouvelle version du fichier), il existe 3 cas possibles :
1) L'information de mise-à-jour n'a pas encore été reçue (cas plus théorique que pratique). Dans ce cas, le fichier binaire n'a pas encore été effacé, et c'est la version précédente du fichier qui est délivrée depuis le disque local.
2) L'information de mise-à-jour a été reçue, le fichier binaire local a été effacé, mais les mécanismes de réplication asynchrone n'ont pas encore ramené en local la nouvelle version du fichier. Dans ce cas, FineFS va récupérer le fichier auprès de son serveur d'origine, l'enregistrer en local, et le délivrer à l'application qui le demandait.
3) L'information de mise-à-jour a été reçue, et la réplication a déjà amené le nouveau binaire jusqu'au serveur. Dans ce cas, la dernière version du fichier est directement délivrée à l'application.

Donc il n'y a pas de problème de cohérence de données. Pour les applications visées, on peut se satisfaire de savoir qu'on a toujours la dernière ou l'avant-dernière version d'un fichier ; sachant que les cas où on va récupérer l'avant-dernière version sont globalement rares.

Quand je dis que FineFS est plus-ou-moins-synchrone, c'est parce qu'une écriture n'est pas bloquante : on n'attend pas que tous les noeuds reçoivent l'information pour dire que l'écriture est réussie. Mais on peut considérer que l'écriture ne sera connue de l'ensemble du cluster que lorsque le message d'information en aura fait le tour (ce qui est très rapide vu la légèreté de ce message).

Cf. Eventually Consistent : http://www.allthingsdistributed.com/2008/12/eventually_consi(...)

Et quand je dis que FineFS est aussi totalement asynchrone, c'est que la recopie des données d'un serveur à un autre peut se faire de 2 façons : soit par le mécanisme de réplication, soit à la demande lorsqu'une machine demande un fichier qui n'est pas disponible en local.

Je ne suis pas certain de comprendre ta deuxième question. Un client ne passe pas par un serveur Web pour récupérer un fichier, FineFS a son propre protocole. Je ne peux que conseiller d'aller faire un tour sur le site du projet, il y a des exemples qui expliquent comment fonctionne FineFS.

Pour répondre au reste, on ne cherche pas à faire plus qu'un système de fichier habituel. Si tu as deux processus qui lisent et écrivent dans le même fichier au même moment sur une partition Ext3, tu risques d'avoir quelques surprises. Je sais que c'est justement pour cela que les filesystems offrent le lock, mais très sincèrement je n'ai pas vu beaucoup d'applications Web qui en avaient l'utilité. Il y a beaucoup plus à gagner de faire un système simple et très efficace, quitte à laisser les cas très particuliers être gérés par les applications en utilisant des systèmes supplémentaires (sémaphore, système de file d'attente partagée, base de données, ...).

Effectivement, les fichiers sont accédés en entier. L'approche de FineFS est de servir rapidement des fichiers de taille raisonnable. Il ne se destine pas à gérer des fichiers de plusieurs centaines de megas (même si c'est faisable) ou de plusieurs gigas ; d'autres filesystems orientés data-grid sont plus efficaces pour cela.

Le cas d'utilisation typique, je le rappelle, est la ferme de serveurs web. Chaque serveur est susceptible d'ajouter de nouveaux fichiers (par exemple des images, des musiques, des vidéos), qui seront ensuite accédés par n'importe quel autre serveur (soit pour modification, soit pour envoyer le fichier à un utilisateur). L'idée est d'accéder rapidement à des fichiers complets, pas de permettre des accès sur des portions de fichiers ; pas de lock, pas de seek.

L'API complète, avec des exemples d'utilisation, est disponible dans la documentation : http://code.google.com/p/finefs/wiki/CodePhp

Non, pas du tout. Pour commencer, memcache sert à stocker des données sous forme de clé-valeur, pas une arborescence de fichiers binaires. Les buts visés par FineFS se rapprochent plutôt de ceux visés par MogileFS (par les mêmes créateurs que memcache).

Au niveau technologique, les données de memcache ne sont pas répliqués, mais réparties. Lorsqu'on a plusieurs serveurs memcache, chaque client va calculer automatiquement sur quel serveur il va aller la stocker ou la récupérer. Si un serveur tombe, la donnée est perdue, mais ce n'est pas un problème (une donnée mise en cache doit pouvoir être recalculée sans trop d'effort, on perd juste ponctuellement le gain de vitesse du cache).

Non, parce que ce serveur de configuration aura aussi des fonctionnalités supplémentaires. Par exemple, lorsqu'on voudra ajouter un noeud supplémentaire dans un cluster (fonctionnalité actuellement impossible à chaud), ce noeud avertira le serveur de conf de sa présence, qui pourra redistribuer l'information aux serveurs actifs.

Tahoe est très intéressant, mais ses buts sont différents. La volonté de préserver les données du regard des administrateurs système les a amené à créer un système très fort du point de vue cryptographique.

L'un des postulats de départ de FineFS est que le cluster s'exécute dans un environnement non hostile. Il n'y a pas de gestion de droits utilisateur, et encore moins d'encryption des données. Cela conduit à un code plus simple.

Un élément important de la conception de FineFS a été la volonté de réduire au maximum les communications réseau. Les données sont accessibles en local la plupart du temps. Et si l'utilisateur qui accède aux données est le même que celui qui gère le noeud FineFS local, il n'y a même pas d'ouverture de socket. Le but est de réduire au maximum les latences d'accès aux fichiers.

Dans le cas d'un frontal web (qui est le cas d'utilisation typique de FineFS), la livraison d'un fichier statique se fait directement depuis le disque local, sans transfert réseau ni recopie de données en mémoire - en tout cas, sans plus de recopie que celles faites en interne par PHP quand on fait un readfile().

Je comprends qu'on puisse se dire que FineFS n'est pas en compétition directe avec les autres systèmes que j'ai cité. Mais si on regarde l'utilisation concrète qu'on en fait, on se rend compte qu'il peut être utilisé dans certains des cas où GlusterFS pourrait être utilisé, mais aussi dans les cas où Amazon S3 est utilisé. Il n'y a pas qu'un seul type de solution acceptable pour répondre au besoin.

GlusterFS est un système qui fonctionne très bien. Mais dans la mesure où les serveurs mettent à disposition leur espace de manière assez simple, la complexité est déportée sur les clients, qui doivent maintenir la cohérence des données à travers le cluster. Les données transitent par le réseau, ce qui incite à l'employer sur des infrastructures assez complexes, sur de très gros clusters connectés en Infiniband - même si, je le repète, GlusterFS fonctionne très bien sur des architectures plus communes.

FineFS est plus simple dans sa conception, et ne vise pas des architectures aussi importantes. L'utilisation typique est le cluster de frontaux web, sur lesquels on peut stocker les données en local pour éviter de faire passer les données sur le réseau. Et sur ce type de cluster, il fonctionne vraiment bien.

Accessoirement, FineFS permet d'associer des méta-données aux fichiers stockés, sans pour autant passer par un serveur central. Et contrairement à GlusterFS, c'est un système répliqué uniquement (et non réparti).

Le sens de la phrase est de dire que FineFS a été développé prioritairement pour des applications Web, donc pour des applications qui n'ont pas de contraintes temps réel fortes.

A contrario, une application avec des contraintes temps réel fortes ferait mieux de se tourner vers un système utilisant des données centralisées (MooseFS, Chirp, Lustre, GfarmFS). Parce qu'il existe un risque théorique qu'une donnée créée sur une machine soit demandée quasi-immédiatement sur une autre machine du cluster, alors que celle-ci n'a même pas encore reçu l'information d'existence du fichier.

En pratique, c'est un cas qui ne pourrait arriver qu'avec un très gros cluster (dépasser la centaine de machines) qui ne serait pas en Ethernet gigabit, ou si un noeud du cluster était ponctuellement tellement chargé que cela induirait des latences sur tout le cluster.

Je comprends que cela puisse sembler pénible. Mais sur un cluster de quelques noeuds, ce n'est pas trop gênant, et c'est ce qu'il y a de plus facile à comprendre et à développer. Parce que recopier la même liste sur tous les noeuds soulevait des problèmes inutiles (recalculer systématiquement où le serveur local se situe dans la boucle de machines, par exemple).

Par contre, nous réfléchissons à développer un serveur de configuration, qui enverra aux différents noeuds les informations dont ils ont besoin pour s'insérer correctement dans le cluster. Il n'y aurait ainsi qu'une seule configuration à maintenir, ce qui faciliterait le travail d'administration. Si ce serveur spécial tombait en panne, cela n'empêcherait pas le cluster de fonctionner. Nous travaillons dessus.

Effectivement, la démarche de FineFS se rapproche de celle de MogileFS. Mais il y a quelques différences de conception, la principale étant que MogileFS nécessite une base de données centralisée (et monter une architecture MogileFS redondée au niveau de la base de données est d'un seul coup bien plus complexe).

Cloudstore est plutôt utilisé par des programmes basés sur le paradigme map-reduce, non ?

FineFS n'est pas POSIX parce que ce n'est pas une nécessité. L'exemple de MogileFS est cité dans un autre commentaire ; il n'est pas POSIX non plus, et ça ne l'empêche pas de remplir son rôle.

Si la compatibilité POSIX devient un élément important, on verra pour le développement d'un driver FUSE.

FineFS ne se destine pas à être généraliste, mais à répondre à un certain besoin de la meilleure manière possible. Le fait qu'il soit écrit en PHP a permis un développement rapide, pour une diminution des performances extrêmement faible par rapport à ce à quoi nous nous attendions.

Oui, c'est vrai, je suis allé un peu vite... Bien vu :-)

L'intérêt du JSON pour autre chose que du Javascript ? Quand tu as besoin de sérialiser/désérialiser des données constituées de types scalaires (chaînes, entiers, flottants), de listes et des tableaux associatifs, c'est quand même vachement pratique.

En PHP, par exemple, on manipule souvent des listes de hashs sans arrêt, voire des listes de listes contenant des hashs qui contiennent des listes, etc. Un petit coup de json_encode() et json_decode(), et tu peux stocker ces données très facilement.

Si on dit que le YAML est super bien pour faire des fichiers de configuration simples à écrire, lisibles par un humain et rapides à parser (cf. la discussion plus haut qui disait que le YAML n'aurait pas pu servir pour stocker un équivalent du SVG), et qu'en cela c'est mieux que JSON et XML, pourquoi ne pas comparer avec un simple fichier INI ?

Alors oui, les fichiers INI ne peuvent pas être super complexes (un seul niveau d'arborescence, des données scalaires ou des listes). Mais niveau lisibilité et simplicité, on fait difficilement mieux. Et pour la rapidité de parse, mes tests le donnent un peu plus rapide que pour du JSON équivalent, et beaucoup plus rapide que du XML équivalent.

Alors bon, même si je ne doute absolument pas des qualités du YAML, j'utilise mon arsenal constitué de INI, JSON et XML, en fonction des besoins. Un quatrième format, ça commencerait à faire beaucoup (sauf peut-être si c'était un format binaire, il y a des cas où ça pourrait être utile).

Je suis rassuré, merci. Je m'en vais l'installer de ce pas ! ;-)

écriture de partitions pour guitare, basse et batterie sous forme de tablatures, mais aussi sous la forme classique en clef de sol

J'espère que c'est juste un raccourci de langage, pour rendre la news plus lisible.

Parce que ça me ferait mal d'écrire des partitions pour basse en clé de sol !

C'est peut-être juste une question de rhétorique.
Est-ce que écrire un fichier XUL pour changer l'apparence de Firefox doit être considéré comme du développement, ou comme du paramétrage ?

2 personnes de ma famille, "plus toutes jeunes", possèdent un Ordissimo, et elles en sont très contentes. Effectivement, le support du WIFI est foireux (la clé Wifi achetée, qui fonctionnait après que j'ai passé 1 heure au téléphone avec leur directeur technique, ne fonctionne plus depuis la mise-à-jour suivante). L'investissement dans un long cable ethernet n'est pas trop ruineux.
Mais à côté de ça, je trouve le système vraiment pas mal du tout. Le clavier simplifié, c'est une vraie bonne idée. Avoir 3 caractères différents sur une touche, c'est une gymnastique intellectuelle pour les débutants. Les applications en plein écran, sans fenêtre, permet aussi de rendre l'interface simple à comprendre pour les néophytes.

Je n'ai pas essayé de les contacter depuis un petit bout de temps, mais à l'époque (il y a un ou deux ans) j'avais eu pas mal d'échanges par email et par téléphone avec leur directeur technique, très sympa, qui m'avait même accueilli dans leurs locaux, où j'avais pu voir l'Ordissimo portable qui était encore un prototype à l'époque.

Concernant les violations de GPL, il me disait que le seul soft propriétaire, c'est leur gestionnaire de fichiers. Le reste (Firefox, Thunderbird et OpenOffice), c'est juste de la configuration, qu'ils ne touchent pas au code. Pareil pour la distribution, c'est plus ou moins basé sur une distribution classique (je sais plus laquelle... Debian peut-être), dont ils ont adapté les mises-à-jour. Le gros du travail semble s'être situé au niveau du window manager, qui a été ultra-configuré pour atteindre ce résultat : pas de fenêtre, et chaque application se lance en plein écran dans un bureau virtuel différent, accessible avec les gros boutons en haut de l'interface.

... le jeu Pandocréon Menhir (http://www.pandocreon-menhir.com ), un jeu sous licence Art Libre qui a remporté le Trophée des Créateur au festival ludique de Parthenay en 2005.

Une micro-édition est en vente, et une version est jouable en ligne (http://www.pandocreon-cromlech.com ).

La règle du jeu dit : "Le but du jeu est de faire pousser plus de menhirs adultes que ses adversaires. En cas d'égalité, le nombre de graines restantes sert à départager les joueurs."

C'est assez clair. Le gagnant est celui qui a fait pousser le plus de menhirs. Si plusieurs joueurs sont à égalité, c'est celui qui possède le plus de graines non poussées qui l'emporte.

L'idée du jeu sur plusieurs années est utilisée dans les règles avancées, où il faut faire autant de manches qu'il y a de joueurs.

Le code source des cartes et de la règle est sous licence libre (au format Carta-Genius, un logiciel sous licence libre proposé aussi par le projet Pandocréon), mais les images elles-même sont uniquement sous le copyright de la graphiste qui les a fait.

Pour la charge serveur, c'est vrai qu'en ce moment les annonces sur TricTrac et LinuxFR ont un résultat un peu violent... ;-)

Oui, c'est évidemment le texte de la règle de jeu qui est placé sous licence libre.