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).
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.
[^] # 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é à 4.
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.