Comment tu gères un "ls" ? Le programme essait de choper un noeud "responsable" mais comment le trouve-t-il ?
Concernant les algo de répartition, vous utilisez du basique, cela va être chaud pour gérer les reconnections. D'ailleurs, si vous gériez un minimum de version du fichier, cela permettrait de garder en mémoire le fichier le plus rescent tout en conservant une copie en cas d'erreur.
Au niveau répartition de fichier,je connais 4 méthodes:
- centralisé, type NFS et votre cas, ou les données sont localisé en un seul endroit. Très efficace si il y a beaucoup d'écriture par rapport au lecture (donc "r" faible qui est le nombre de lecture pour une écriture) avec beaucoup de noeud y accédant, il faut évidement que le nombre global de pair soit faible sinon, tout s'écroule.
- migration, en gros, un écrivain, récupère le fichier et devient son propriétaire, c'est très efficace si il y a peu de noeud qui y accède en simultané. (par définition, un /home devrait être gérer comme cela)
Les 2 autres type utilisent la réplication, la différence concerne la gestion des écritures
- read replication, implique une invalidation des autres copies. C'est efficace avec beaucoup de pair qui écrivent peu.
- write replication, implique un broadcast des modifications à toutes les copies. C'est efficace avec peu de pairs qui écrivent beaucoup.
Typiquement, aucun des 4 algo est mieux que les autres cela dépend du nombre de pair, du taux d'écriture, du coût de transfert d'un message par rapport à la taille du fichier.
Si tu veux gérer plusieurs copies, le read replication est pas mal, mais je pense qu'il faut limiter le nombre de copie et utiliser un peu de migration, sinon la gestion des metadonnées devient horrible.
Pour retrouver les objets en cas de migration, les anciens propriétaires conservent l'adresse du nouveau propriétaires, ils peuvent ainsi gérer des indirections.
Et d'ailleurs gères-tu de la même façon une ISO de 4Go et un fichier de conf de 4Ko ? Il serait peut-être intéressant de jouer avec des "morceaux" histoire de mutualiser la bande passante.
[^] # Re: Algo ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Peerfuse, filesystem distribué. Évalué à 4.
Concernant les algo de répartition, vous utilisez du basique, cela va être chaud pour gérer les reconnections. D'ailleurs, si vous gériez un minimum de version du fichier, cela permettrait de garder en mémoire le fichier le plus rescent tout en conservant une copie en cas d'erreur.
Au niveau répartition de fichier,je connais 4 méthodes:
- centralisé, type NFS et votre cas, ou les données sont localisé en un seul endroit. Très efficace si il y a beaucoup d'écriture par rapport au lecture (donc "r" faible qui est le nombre de lecture pour une écriture) avec beaucoup de noeud y accédant, il faut évidement que le nombre global de pair soit faible sinon, tout s'écroule.
- migration, en gros, un écrivain, récupère le fichier et devient son propriétaire, c'est très efficace si il y a peu de noeud qui y accède en simultané. (par définition, un /home devrait être gérer comme cela)
Les 2 autres type utilisent la réplication, la différence concerne la gestion des écritures
- read replication, implique une invalidation des autres copies. C'est efficace avec beaucoup de pair qui écrivent peu.
- write replication, implique un broadcast des modifications à toutes les copies. C'est efficace avec peu de pairs qui écrivent beaucoup.
Typiquement, aucun des 4 algo est mieux que les autres cela dépend du nombre de pair, du taux d'écriture, du coût de transfert d'un message par rapport à la taille du fichier.
Si tu veux gérer plusieurs copies, le read replication est pas mal, mais je pense qu'il faut limiter le nombre de copie et utiliser un peu de migration, sinon la gestion des metadonnées devient horrible.
Pour retrouver les objets en cas de migration, les anciens propriétaires conservent l'adresse du nouveau propriétaires, ils peuvent ainsi gérer des indirections.
Et d'ailleurs gères-tu de la même façon une ISO de 4Go et un fichier de conf de 4Ko ? Il serait peut-être intéressant de jouer avec des "morceaux" histoire de mutualiser la bande passante.
"La première sécurité est la liberté"