Peerfuse est un système de fichier distribué pair à pair écrit en C++ avec la bibliothèque FUSE et initié il y a quelques mois.
Le projet, dont une description peut être lue ici, a pas mal avancé et une version 0.1 va paraître d'ici quelques jours.
Bien évidemment, beaucoup reste à faire, la release a pour unique but de présenter à la communauté les bases d'un projet qui est déjà fonctionnel mais limité.
Vous pouvez voir ici les fonctionnalités actuellement implémentées, et ici une description de nos premiers essais sur internet du projet.
C'est un projet assez novateur et dont les tentatives similaires (mais n'ayant pas le tiers des fonctionnalités que nous proposons) sont toutes tombées à l'eau. Je pense que les développeurs de Peerfuse ont la volonté suffisante pour que ça ne soit pas le cas avec ce projet.
Si vous êtes intéressé par ce projet, que ça soit en tant que contributeur ou même en tant qu'utilisateur, vous pouvez trouver quelques informations sur le site, http://peerfuse.org, ainsi que sur le salon IRC dédié au projet, #peerfuse@freenode.
En outre, les développeurs et divers futurs contributeurs ont prévu de boire un verre vendredi 2 mai à 19h00 au Dock's café (Paris XIXe, un plan d'accès se trouve sur leur site) afin d'échanger sur le projet autour d'une bonne bière. N'hésitez pas à passer.
Journal Peerfuse, filesystem distribué
1
mai
2008
# Très bonne idée
Posté par seginus . Évalué à 9.
Est-ce que peerfuse enlarge your penis ?
[^] # Re: Très bonne idée
Posté par Gniarf . Évalué à 10.
[^] # Re: Très bonne idée
Posté par seginus . Évalué à 8.
[^] # Re: Très bonne idée
Posté par Régis . Évalué à -3.
Si tu à peur du regard dans les vestiaires bah utilise vim et tu verra ta virilité s'en ressentira ;)
# Bonne idée
Posté par seginus . Évalué à 3.
J'ai voulu aller voir un peu plus en avant, mais je n'ai pas eu le temps, et ça m'a par la suite échappé.
Linux a une conception multiutilisateur, mais tellement grande que ce n'est pas toujours très évident de partager parfois même au seins d'un même ordinateur.
En fait, ce que je souhaitais à la base, c'est une option dans chmod (tel +g), qui permet d'avoir en quelque sortes un dossier sans permissons.
Mais peerfuse permet d'aller plus loin en facilitant la création d'un tel dossier sur tout un réseau.
Je pense que ce projet peut avoir de l'avenir si il est par la suite bien intégré et simple d'utilisation.
Bonne chance et merci pour votre travail. (vous la méritez cette bière)
[^] # Re: Bonne idée
Posté par Rémi baudruche . Évalué à 2.
que veux tu dire par un dossier sans permission ?
[^] # Re: Bonne idée
Posté par seginus . Évalué à 3.
Ce que je fais :
un groupe partage, un chmod 775 et un chmod g+s
le g+s fait que les fichiers créer dans ce dossier auront lautomatiquement comme groupe partage.
Je change aussi le umask de /etc/profile de 022 à 002 (je comprend pas trop cette politique par défaut des distibutions, si on fait ur groupe particulier, c'est généralement pour donner des privilèges particuliers.
Avec cette méthode, les fichiers copiés dans ce dossier se comporte comme voulu : tout le monde peut les lire, les modifiers et le effacer (tout ceux du groupe partage). Où est le problème alors me direz-vous ?
il vient du déplacement de fichiers qui lui ne va pas modifier les permissions. ou le groupe d'utilisateur.
Donc typiquement, je télécharge la vidéo d'une conférence sur internet que je veux mettre en partage. Vu la taille, je la déplace et ne la copie pas, et voilà, un fichiers se retrouve au milieux avec de mauvais attributs
Une solution que je vois est de mettre en groupe partage par défaut les utilisateurs, mais ce n'est pas forcément souhaité, de plus il y aurait aussi problème avec les programmes qui mettent leur propre permission lors de la création de fichiers (par exemple xsane, pas bien compris pourquoi d'ailleurs).
C'est donc possible d'avoir ce qu'on veut en configurant tout bien ensuite chaque logiciels, mais il faut reconnaiître que c'est très lourd à mettre en place, et que de plus on est pas à l'abrit d'un « mauvais » fichiers dans une archive type tar.
Voilà tout les problèmes que je trouve fréquemment.
[^] # Re: Bonne idée
Posté par Romain . Évalué à 3.
[^] # Re: Bonne idée
Posté par ckyl . Évalué à 3.
La partie intéressante est: " 1. The new object inherits the default ACL of the containing directory as its access ACL.".
# Extensibilité
Posté par yellowiscool . Évalué à 5.
Envoyé depuis mon lapin.
# Autres solutions ?
Posté par Clément David (site web personnel) . Évalué à 2.
Pour moi l'avantage du système de fichier basé sur FreeNet est le réseau déjà existant se qui garanti des temps d'envoi lors d'un dépot.
Pense tu qu'il soit possible de couplé les permissions UNIX avec celle du réseau FreeNet (sorte de backend à FreeNetFS) afin de conserver la simplicité ?
En tous cas bonne chance pour ton projet très prometteur.
[^] # Re: Autres solutions ?
Posté par lodesi . Évalué à 1.
# Algo ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Algo ?
Posté par Romain . Évalué à 3.
Par la suite, il y aura un système de création de redondance automatique. C'est à dire que pour éviter que la disponibilité d'un fichier repose sur un seul pair tant que personne ne l'a récupéré, au moment de la création de celui-ci, quelques pairs le récupèreront automatiquement et le stockeront dans leur cache.
Pour retrouver les fichiers, nous utilisons (sur peerfuse-net) un système de distribution de l'arbre. C'est à dire que pour chaque fichier, il y a des pairs responsables. Connaître les responsables passe en gros par un hash du path du fichier, utilisé dans une formule pour retrouver les IDs à partir de la liste triée. Cela implique malheureusement un changement de responsables lorsqu'un pair joint ou quitte le réseau, et ainsi que les anciens responsables envoient les messages de mise à jour aux nouveaux responsables. Note que des optimisations sont possibles mais non effectuées encore.
Tu trouveras plus d'informations (et l'algorithme) là dessus ici : https://anonymous:@piggledy.org/svn/peerfuse/trunk/doc/proto(...) (pass vide, et rédigé à la rache).
Cela dit, encore une fois le projet est en plein cours de développement, si tu as des idées/suggestions, n'hésite pas :)
[^] # Re: Algo ?
Posté par Nicolas Boulay (site web personnel) . É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é"
[^] # Re: Algo ?
Posté par lodesi . Évalué à 1.
En gros, les fichiers sont gérés à partir d'un hash sur le nom de fichier. Quand on fait un ls on prend le hash du nom de fichier et ça nous donne la liste des peers ayant les infos sur ce fichier (contenu du répertoire, quels peers possèdent le contenu du fichier ...). Cette méthode permet d'économiser de la bande passante et aussi donne une certaine réactivité quand on fait un ls ;)
Sur pf-lan:
Chaque peer connait en permanence le contenu des dossiers, les modifications sont synchrones et broadcastées.
Pour les datas, c'est commun aux 2 fs:
Dans pf-0.1, le fichier est récupéré au moment de la lecture, la copie est gardée en cache. Lorsque quelqu'un modifie le fichier toute les copies existantes sont invalidées.
Dans pf-0.2, lorsque le cache est plein on le vide, avec migration de fichier sur une autre machine si nécessaire. (donc oui sur la 0.1, le cache explose si on n'y fait pas attention :)
Ca c'est le fonctionnement de base, un peu plus tard on pourra définir un taux de redondance sur le réseau qui propagera les modifications sur un fichier, et on rajoutera surement des fonctions de prefetch... et plein de bonnes choses sont encore à définir pour le version suivantes :)
[^] # Re: Algo ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Par définition, le cache à une taille fixe, et cela doit rester un cache, c'est à dire que l'on compte dessus pour des raisons de performances et non pour conserver l'information. En gros, il faut pouvoir le détruire.
Sinon, la différence entre net et lan, c'est la bande passante disponible et le nombre de pair, pourquoi ne pas avoir fusionner les 2, et prendre en compte ce paramètre pour choisir la stratégie de diffusion ?
Si j'ai bien compris le système tous les pairs contiennent les meta-données ? En fait, tous les pairs se connaissent tous en entre eux. Cela ne limite pas la taille du réseau possible ?
"La première sécurité est la liberté"
[^] # Re: Algo ?
Posté par lodesi . Évalué à 1.
A l'utilisation, la différence entre pflan et pfnet se fait essentiellement sur la gestion des permissions : pflan distribue des fichiers en utilisant les permissions UNIX de la machine (un user avec un même UID accède aux mêmes fichiers depuis toute les machines), pfnet gère les permissions à partir du certificat passé au démon, càd un démon égal un utilisateur (la gestion des groupes ne se fait donc pas avec /etc/group, mais avec des commandes spécifiques pfnet). Une autre différence majeur entre pfnet et pflan se situe au niveau du réseau, pflan demande à ce que tout les peers puisse se connecter les uns aux autres, alors que pfnet implémente un routage des messages en utilisant d'autres peers comme passerelle (pour gérer les utilisateurs derrière des routeurs NAT).
Pour la gestion des méta-données, les peers stockent toutes les méta-données sur pflan. Ce n'est pas le cas sur pfnet, car un peer n'a pas accès à tout les fichiers. Dans les 2 cas tout les peers se connaissent les un les autres (y'a bcp de broadcast dans pflan, mais pas dans pfnet).
On n'a pas vraiment étudié les limitations, ce n'est pas encore prioritaire ;)
Voilà, maintenant que tu connais tout les détails de l'implémentation, je t'invite à venir contribuer sur peerfuse ! :)
Bref, passe sur #peerfuse@freenode.net si tu veux tester ou si t'as d'autres questions.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.