Gibt es ein P2P-Netzwerkdateisystem (fürs LAN)?

_hephaistos_ · Posted: Tue Jun 07, 2005 9:59 am Post subject:

also ein "Client" ist bei dir eigentlih auch ein Server oder? dh: hohe Verfügbarkeit zu erwarten?
die Idee find ich cool!
ev. bereden wir das am Usertreffen dann - mom. hab ich keine Zeit.
und wer verwaltet nun die IDs? dh: es müsste ja einen "Masterserver" geben, der Infos über ALLE Dateien (mit IDs) hat.
Dateien zerstückeln würd ich anfangs weglassen...

cheers

Hilefoks · Posted: Tue Jun 07, 2005 10:10 am Post subject:

Moin,

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

_hephaistos_ · Posted: Tue Jun 07, 2005 10:15 am Post subject:

ja, da eigenet sich aber dann multicast!
dh: alle "clients" joinen einer gruppe und fertig.

@slick: jetzt versteh ich auch, wie du das meinst! dh: server nicht notwendig, weil multicast. dh: die clients organisieren sich untereinander.

cheers

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

Zu den Dateien statt Blöcken, also ich sehe das so das es mir eben möglich sein sollte Dateien abzuspeichern die in Ihrer Größe die Gesamtgrößes eines Client übersteigen. Desweiteren (mir grad beim Hühnchen-Essen so eingefallen) hat es einen Vorteil: Wenn man die eindeutige ID des Blockes festmacht an seinem Inhalt, könnte man u.U. sogar was an Plattenplatz sparen, da ja z.B. bei den Distfiles die Unterschiedes von Sourcen des gleichen Paketes nicht groß sein müssen (und so bestimmte Blöcke binär identisch) So könnte man eine gewisse "Komprimierung" erreichen.

_hephaistos_ · Posted: Tue Jun 07, 2005 10:57 am Post subject:

jo, hast recht.
es sollte eine art hashfunktion für die berechnung der ID geben.
dh: dateiname+md5(content)+filetype+blocknummer irgendwie verhashed

das wär dann eindeutig. wobei md5(content) wahrscheinlich ein problem sein kann....

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

Ich würde nur den Inhalt verhashen, über mehrere Hashfunktionen um Fehler zu vermeiden und um EinEindeutigkeiten zu schaffen. Bezieht man den Dateinamen mit ein geht der "Komprimierungseffekt" verloren. Der sollte zwar eh nur bei bestimmten Dateien (distfiles) und bei einer bestimmten Blöckgröße auftreten, zumindest könnte ich damit theoretisch eine 100GB Datei voll mit Nullen auf einem 1MB-Client ablegen ;-)

EDIT: Natürlich muß dann je Client eine Tabelle existieren die Blockhash und Dateiname/Blocknummer zusammenführt.

Hilefoks · Posted: Tue Jun 07, 2005 11:57 am Post subject:

Im Grunde müsste das Ding also wie ein Mule-Client funktionieren, - mit der Erweiterung das der Client selbstständig einen Datei-Upload bzw Download macht, - je nachdem wieviele Quellen erreichbar/existent sind!?

m.b.j. · Posted: Tue Jun 07, 2005 1:59 pm Post subject:

Mhh die Idee mit der Kompression ist nicht schlecht, allerdings glaub ich nicht, dass sie so größe Erfolge verzeichnen wird, da sich gleiche Blöcle wohl nicht so einfach finden lassen werden (erledigt gzip nich schon das Blocksortieren?), leider habe ich keine Idee wie ich eine Datei in mehrere Blöcke aufzuteilen habe (auf der Kommandozeile zum testen, ob sich eine Platzersparniss bei fast gleichen Distfiles erreichen lässt), falls was aus dem Projekt wird, hab ich allerdings einen Namensvorschlag= genfs !

Falls mir jemand mitteilt wie ich eine Datei auf der Kommandozeile in Blöcke aufteilen kann werde ich in ruby ein kleines Script basteln, dass ein paar Distfiles zerlegt und die mögliche Plaztersparniss überprprüft!
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

split ?

the-pugnacity · Posted: Tue Jun 07, 2005 2:39 pm Post subject:

geht eventl. GFS von dem roten Hut in die Richtung??
http://www.redhat.com/software/rha/gfs/
_________________
Gentoo 2.6.12-gentoo // Pentium4 2800 || Aopen XC Cube || TwinMOS 1024 MB PC 3200 || 250GB Hitachi 7k250 || Aopen Aeolus FX5900XT || MX500

m.b.j. · Posted: Tue Jun 07, 2005 2:41 pm Post subject:

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

m.b.j. · Posted: Tue Jun 07, 2005 6:37 pm Post subject:

Zum Thema Blöcke mehrfach nutzen, hab ich mit folgendem Ruby Code rumgespielt:

_hephaistos_ · Posted: Tue Jun 07, 2005 6:53 pm Post subject:

@mjb: ich glaub die schwierigkeit liegt nicht darin, sondern wie sich die clients unterhalten. wie man "daten abgleicht" etc...
naja und was gscheites sollte schon in PURE C sein

cheers

m.b.j. · Posted: Tue Jun 07, 2005 7:03 pm Post subject:

Wollt doch nur ausprobieren, ob sich das lohnt, das Kompressionsfeature einzubauen... (und das bei gzip Dateien wohl nicht)... Das ruby nicht die Lösung für sowas ist, ist mir klar *g*
_________________
root@mbj # echo "sys-pizza/calzone -tunfish" >> /etc/paludis/use.conf
root@mbj # paludis -i calzone --dl-blocks discard

_hephaistos_ · Posted: Tue Jun 07, 2005 7:13 pm Post subject:

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

Also bei meinen Überlegung bin ich davon ausgegangen das jeder Client unmittelbar direkt erreichbar ist (und nicht bei Tauschbörsen "weit" weg liegt).

Zum Abgleich der Daten:

- um erstmal eine Grundstruktur reinzubekommen wäre zu überlegen ob man das als "richtiges" fs macht oder "nur" als "einfache" Ressource
- ist es ein richtiges fs sollte es einen "Master" geben der allein Schreibrechte darauf hat, so ist sichergestellt das dieser das schreiben koordiniert (nur ein Client einen Block beschreiben darf, und nicht zwei Clients einen gleichzeitig, hier sehe ich sonst Probleme)
- ist es ein "Tauschbörsen"-fs müßte jeder Client in das Netz schreiben können
- welches der beiden Möglichkeiten ich favorisiere kann ich noch nicht sagen

Der Abgleich der Daten sollte meinem schonmal grob beschriebenen Prinzip folgen: (nur Grundidee!)

Schreiben:

Prinzip 1:
- gegeben sei: Client A, B und C schon mit mehreren Blöcken von Dateien
- Multicast von Client B trifft ein mit Aussage: ich habe hier den Block X und möchte den wo ablegen, wer hat Platz?
- Client A prüft: Habe ich Block X schon -> Nein
- jetzt sendet Client A "ok, habe den Block nicht und habe noch n MB Platz frei" (Client C macht das gleiche)
- Client B liest das jetzt von A und C und "überlegt": "Ok, Client A hat 10 MB frei, Client C hat 100MB frei... außerdem hat C schneller geantwortet" -> Client B sendet Block an Client C

Prinzip 2:
- gegeben sei: Client A, B und C schon mit mehreren Blöcken von Dateien
- Multicast von Client B trifft ein mit Aussage: ich habe hier den Block X und möchte den wo ablegen, wer hat Platz?
- Client A prüft: Habe ich Block X schon -> Ja
- Client A Sendet: "Ja, ich habe den Block und habe momentan noch 10MB frei" (Client C macht das gleiche)
- Client B bekommt jetzt die Meldung das A und C den Block schon haben
- Client B entscheidet: "Wenn A und C den Block schon haben und C hat aber mehr Speicherplatz frei, dann sollte C und ich den Block speichern denn bei A sieht es knapp aus"
- Client B weist Client A an seinen Block zu löschen und kopiert seinen Block an C

Jeder Client führt eine Liste mit seinen Blöcken und mit "Erstellungsdatum", sortiert nach "Erstellungsdatum", in einem Rhytmus prüfen nun alle Clients die "ältesten" Blöcken und deren Redundanz im Netz. Ist der Block nur auf dem prüfenden Client wird nach dem o.g. Prinzip 1 der Block weiter verteilt oder ist er auf mehr als 2 Clients dann werden nach Prinzip 2 "Überredundanzen" gelöscht (evt. in Abhängigkeit von der Häufigkeit des Zugriff)

Lesen:

- Client A möchte die Datei XYZ lesen, also prüft er erstmal seine Datei-zu-Block Liste (oder "besorgt" sich die Liste):
- "Ich brauche Block 1 bis 5, ich selbst lagere Block 1-3, ich brauche also noch Block 4-5"
- Client A fragt nun im Netz wer denn den Block 4 oder 5 hat und bekommt die Antworten von mehreren Clients
- jetzt kann A "überlegen" -> Client C hat den Block, der hat aber nurnoch wenig Speicher frei und hat langsam geantwortet, also wäre es schlauer wenn ich als Client den Block speichere und den C löschen lass"
- da der Block zum lesen eh zu Client A muß, speichert Client A den Block und sagt C das er den Block löschen kann (wenn denn die Redundanz erfüllt ist)
- Client A setzt die Datei aus den Blöcken zusammen und "markiert" sich die Blöcke das diese von diesem Rechner öfters gelesen werden und daher "hier" liegen sollten

EDIT: Es klingt im ersten Moment nach viel Traffic, doch das wäre auszuprobieren, denn wenn ich davon ausgehe das standardmäßig ein kleines Netz ist, alle Clients im Netz "da" sind und das entsprechend schnell ist sollte außer beim Schreiben kaum was synchronisiert werden. Erst wenn ein Client "ausfällt" sollte ein gewisser Traffic entstehen. Die geschätze optimale Netzgröße setze ich mal bei 4-10 Clients an. Größere Netze sollten in entsprechend kleinere logische "Subnetze", also je ein "Datenträger", aufgeteilt werden.

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495

So, wir hatten ja auf dem Usertreffen die Gelegenheit das ganze mal bei einem (oder waren es mehr ;-)

) Bier durchzusprechen. Aber ich habe keine Ahnung ob ich das noch auf die Reihe bekomme das zu erklären. Ich glaube ich schlaf erstmal nochmal drüber... _hephaistos_ oder Hilefoks bringst du uns nochmal auf Stand?

_hephaistos_ · Posted: Sun Aug 14, 2005 10:38 pm Post subject:

ChrisM87 · Posted: Mon Aug 15, 2005 12:17 am Post subject:

Hi,

also ich find euer Projekt mal superinteressant und denke, dass das auch eine ziemlich große Usergemeinschaft finden würde (wenn ich nur mal daran denke, wieviel GB hier noch ungenutzt irgendwo sind und meine beiden Platten, die hier eingebaut sind, sind schon hart am Limit...).

Wenn's also was Neues gibt, bitte sofort hier posten!

Leider hab ich von Kernelprogrammierung (im Prinzip alles unixspezifische, also wie man z.B. per FUSE Dateisysteme verwaltet) keine Ahnung, ich C/C++ und Socketprogrammierung bin ich aber schon relativ erfahren, würde ich mal sagen. Wenn ihr das Ganze also wirklich umsetzt (SF-Projekt?), könnt ihr mich mal kontakten.

ChrisM
_________________
born to be root - sorry for my bad English!

supermihi · Guru Joined: 09 Feb 2005 Posts: 348

Hi,
der Thread ist schon alt, aber ich suche gerade genau so etwas (siehe https://forums.gentoo.org/viewtopic-t-472442.html. Spricht was dagegen einfach ein distributed filesystem wie Coda zu benutzen und einfach nicht zwischen servern und clients zu unterscheiden? Oder skalieren die so grottig schlecht dass das bei 25 Servern Probleme gibt?
_________________
"You may say I'm a dreamer, but I'm not the only one."

Haldir · Guru Joined: 27 Sep 2002 Posts: 546

Die skalieren grottig schlecht.

Die Idee gabs schonmal für distributed p2p/grid Backup, Backup übers Internet, jeder stellt einen kleinen Teil speicher zur Verfügung speichert Teile anderer Leute Backups (verschlüsselt)

Ist aber für Windows:
http://sourceforge.net/projects/hispread/

Ansonsten solltest du eher in der Gridcomputing suchen

Ich kenn sonst noch HP SFS (Scalable File Share), ist aber kommerziell und nicht für 5 Rechner gedacht

Ansonsten gibts zu dem Thema einige Diplomarbeiten/dissertationen.

Meistens scheiterts einfach an der Redundanz, mit der Frage wieviel Rechner müßen online sein um eine Datei bereitzustellen und Sicherheitsaspekte, z.b. wie ungeprüft/aus welchen Quellen replizieren sich Blöcke die du verteilst, insb. in Hinblick auf Hashes die nicht wirklich sicher sind ala MD5, wenn du erlaubst einen Block von beliebigen Nodes zu replizieren, kann ein Angreifer einen falschen Block mit korrektem Hash einschleusen und u.U. verteilt sich der Block dann und deine Daten usw. sind im Eimer. Zusätzlich brauch man noch eine Form von distributed load balancing (ähnlich von Eddies für DSMS).

Der einfachste Weg sowas zu implementieren im (sicheren) LAN mit (Raid 1) ist ein AVL Baum, jedes Blatt ist ein Block, damit ist jeder Block doppelt gespeichert (wenn man 2^n Blätter hat), zusätzlich muß jeder Block noch Raid5 ähnlich gespeichert werden, falls ein kompletter Ast abfällt und genau da ist das Problem, du müßtest n andere Blöcke/Blätter updaten um Raid5 aufrecht zu erhalten.
Daher müßtest du wohl einen n-ary balanced Tree ausprobieren, ein Baum der k^n Blätter hat und jeder Block wird k mal repliziert.

Freiburg · Guru Joined: 19 Jun 2004 Posts: 504 Location: Freiburg

@haldir das mit dem AVL-Baum hab ich nicht so ganz verstanden, bist du sicher das du einen AVL-Baum meinst? Meines Wissens nach ist ein AVL-Baum ein Binärsuchbaum, in dem der Höhenunterschied in jedem Ast nicht größer ist als 1. Von einer Redundanz kann ich da nichts erkennen sonst würde ja die Binärsuchbaum Eigenschaft verloren gehen.

Das Hauptproblem wird die Redundanz sein, AFS etc. sind darauf ausgelegt das immer eine Anzahl von "Hauptserver" im Netz sind die sicherstellen das die Daten zur Verfügung stehen. Der Ansatz der hier nötig wäre ist das die Daten auf jedem Rechner vorhanden sind, so das selbst wenn alle anderen Nodes offline sind noch alle Daten zur Verfügung stehen. Je nach dem könnte man das Modell auch dahingehend erweitern das der User sagen kann welches File er gerne immer zur Verfügung haben will und welches nicht. Was auf jeden Fall interessant ist, ist das man einfach und vor allem performant eine Datenmenge in einem Netzwerk Synchron halten kann. Für Schreibzugriffe müsste gewährleistet sein, das ein Locking im gesamten Netzwerk möglich ist. Da es sich um kleine Netzwerken (z.B. <20 Rechner) handelt sollten eigentlich alle Nodes des Netzwerkes bekannt sein, so das ein Locking nicht sonderlich schwer sein sollte, Das Syncronisieren könnte dann geschehen in dem die Änderungen an eine kleine Anzahl von Nodes im Netz weiter gegeben werden, welche dann ihrerseits die Änderungen an weitere Nodes weitergeben.

slick · Bodhisattva Joined: 20 Apr 2003 Posts: 3495