L'intérêt du cache serait de ne pas obliger toutes les machines du cluster à stocker l'intégralité des données. Ainsi, on pourrait imaginer un cluster où certaines machines ont de très gros disques et stockent toutes les données, pendant que les autres machines - qui ont des disques de taille plus raisonnable - stockent en local les fichiers les plus utilisés.
C'est assez évident pour une infrastructure dans laquelle les serveurs frontaux (qui ont besoin des fichiers) ont rarement des disques de plusieurs téra-octets, alors que l'ensemble du cluster est susceptible de stocker des téras au final. C'est plus efficace, toujours dans l'optique de lire en local les fichiers dont on va avoir besoin le plus souvent.
Maintenant, je suis d'accord que ça va complexifier le code de FineFS. Mais c'est moins complexe à gérer qu'un système où les fichiers ne sont répliqués que sur certaines machines (ta proposition précédente).
Donc, on codera sûrement un jour ce système de cache, mais en séparant intelligemment le code, pour ne pas charger la partie qui gère le cache si on n'en a pas besoin.
On ne va pas gérer un cache RAM. Pour commencer, FineFS est sans état. Même le démon n'est pas chargé en mémoire de manière continuelle (il est lancé par xinetd). Ensuite, ça complexifierait le code inutilement ; même le jour où on voudra stocker les méta-données dans une base de données, on le fera sûrement en utilisant SQLite plutôt qu'en gardant les infos en RAM.
Parce que garder un cache en RAM, c'est plus facile à dire qu'à faire de manière stable et efficace. Il faut mettre en place de la communication inter-processus, avec de la mémoire partagée ou un démon local sur lequel il faut se connecter (et hop, encore une ouverture de socket en plus !). Non, le gain est trop faible et hypothétique pour se lancer là-dedans.
[^] # 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 assez évident pour une infrastructure dans laquelle les serveurs frontaux (qui ont besoin des fichiers) ont rarement des disques de plusieurs téra-octets, alors que l'ensemble du cluster est susceptible de stocker des téras au final. C'est plus efficace, toujours dans l'optique de lire en local les fichiers dont on va avoir besoin le plus souvent.
Maintenant, je suis d'accord que ça va complexifier le code de FineFS. Mais c'est moins complexe à gérer qu'un système où les fichiers ne sont répliqués que sur certaines machines (ta proposition précédente).
Donc, on codera sûrement un jour ce système de cache, mais en séparant intelligemment le code, pour ne pas charger la partie qui gère le cache si on n'en a pas besoin.
On ne va pas gérer un cache RAM. Pour commencer, FineFS est sans état. Même le démon n'est pas chargé en mémoire de manière continuelle (il est lancé par xinetd). Ensuite, ça complexifierait le code inutilement ; même le jour où on voudra stocker les méta-données dans une base de données, on le fera sûrement en utilisant SQLite plutôt qu'en gardant les infos en RAM.
Parce que garder un cache en RAM, c'est plus facile à dire qu'à faire de manière stable et efficace. Il faut mettre en place de la communication inter-processus, avec de la mémoire partagée ou un démon local sur lequel il faut se connecter (et hop, encore une ouverture de socket en plus !). Non, le gain est trop faible et hypothétique pour se lancer là-dedans.