Non, c'est l'inverse : Si on ajoute la gestion de 2 types de machines (les noeuds globaux et les noeuds avec cache), cela va augmenter la complexité du software (des cas supplémentaires à gérer) pour diminuer les prérequis sur le hardware (pas besoin que toutes les machines aient des disques assez gros pour contenir toutes les données du cluster).
C'est une question complètement décorrélée de la problématique de l'ajout/suppression de machines à chaud, qui reste compliquée qu'il y ait un seul type de noeuds ou deux.
Pour le reste, on a sérieusement pensé à memcache (on l'utilise déjà pour le cache des applis web). Mais au final, c'était une fausse bonne idée : la récupération d'un fichier de moins de 200 octets n'est pas drastiquement plus rapide via memcache qu'en le lisant sur le disque. Il y a des couches logicielles en plus, des ouvertures de sockets, des copies de données... sans parler du fait de devoir gérer les éventuels problèmes de connexion sinon on risque d'avoir tout le système qui tombe (ou simplement qui ralentit) parce que memcache est en rade.
Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS). Ainsi, il serait possible de rechercher des fichiers à partir de leurs méta-données, et non pas simplement récupérer des méta-données à partir du nom de fichier.
Cela permettrait d'avoir un système de données non relationnel (cf. Dynamo d'Amazon ou Cassandra de Facebook) qui resterait très performant même sur un très grand nombre de serveurs. Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
C'est une question complètement décorrélée de la problématique de l'ajout/suppression de machines à chaud, qui reste compliquée qu'il y ait un seul type de noeuds ou deux.
Pour le reste, on a sérieusement pensé à memcache (on l'utilise déjà pour le cache des applis web). Mais au final, c'était une fausse bonne idée : la récupération d'un fichier de moins de 200 octets n'est pas drastiquement plus rapide via memcache qu'en le lisant sur le disque. Il y a des couches logicielles en plus, des ouvertures de sockets, des copies de données... sans parler du fait de devoir gérer les éventuels problèmes de connexion sinon on risque d'avoir tout le système qui tombe (ou simplement qui ralentit) parce que memcache est en rade.
Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS). Ainsi, il serait possible de rechercher des fichiers à partir de leurs méta-données, et non pas simplement récupérer des méta-données à partir du nom de fichier.
Cela permettrait d'avoir un système de données non relationnel (cf. Dynamo d'Amazon ou Cassandra de Facebook) qui resterait très performant même sur un très grand nombre de serveurs. Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...