| View previous topic :: View next topic |
| Author |
Message |
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
 Posted: Mon Jun 19, 2006 2:04 pm Post subject: |
 |
|
moin zusammen,
ich finde diese idee eigentlich auch recht interessant & wenn ich mal wieder etwas zeit habe (semesterferien) würde ich mich gerne euch anschließen (Hab fundierte C/C++ Kenntnisse).
was mir noch zur kompression eingefallen ist: im prinzip brauch das die software gar nicht machen: man kann doch einfach ein virtuelles kompressionsfs drüber legen, oder?
Tschö mit ö
Manuel
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
 |
Haldir
Guru
Joined: 27 Sep 2002
Posts: 546
|
| Posted: Mon Jun 19, 2006 3:04 pm Post subject: |
|
|
| Freiburg wrote: | @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.
|
Ok mal anders ausgedrückt, stell dir einen Baum vor, der jeweils pro Knoten in zwei (alternativ k) Blättern endet, jedes Blatt ist ein Datenblock, du hast wenn du jetzt zwei Knoten hast, enden die beide in 4 Blättern, auf die verteilst du 2 Blöcke (jeweils ein Block auf jedem Knoten), wenn du das ganze auf k Blätter aufbläst und viel mehr Knoten hast, hast du so gewisse Redundanzen (jeweils Block Kopien), wenn jetzt aber ein Knoten ausfällt (also x Blockkopien fehlen), ist der Höhenunterschied in den Ästen nicht mehr <=1, d.h. du mußt deinen Baum neusortieren damit die Blockkopien wieder gleichmäßig verteilt sind (ansonsten kann es z.b. passieren dass 2 Knoten ausfallen wo einmal Block 1&2 und Block 2&3 dranhängt) und damit Block 2 u.U. nicht mehr vorhanden ist (weil am 3. Knoten z.b. Block 1&3 hängen und dann kannst du Block 2 nur noch rekonstruieren wenn Block 1 oder 3 dann Raid5 ähnliche Redundanzinformationen hast) (du mußt jetzt die Blätter so neu umsortieren das sie wieder gleichmäßig verteilt sind). Das war der Bezug auf selbstbalancierende Bäume, ist zwar nicht 100% nen AVL Baum, aber die restlichen self-balancing Trees kennen noch weniger Leute, ist zwar nicht ganz korrekt und wirklich performant, aber technisch so einfach zu realisieren.
So in etwa, hoffentlich leichter zu verstehen  |
|
| Back to top |
|
|
Freiburg
Guru
Joined: 19 Jun 2004
Posts: 504
Location: Freiburg
|
| Posted: Mon Jun 19, 2006 3:19 pm Post subject: |
|
|
| Den selben Effekt hättest du dann aber auch wenn du in jedem Knoten speichern würdest auf welchen Nodes die Daten zu finden sind. Außerdem glaub ich nicht das ein Binärsuchbaum die richtige Datenstruktur für sowas ist. Es geht ja mehr darum das jeder weiß wo die Teile einer Datei liegen, da würde eine Hashtabelle eher passen... |
|
| Back to top |
|
|
supermihi
Guru
Joined: 09 Feb 2005
Posts: 348
|
| Posted: Mon Jun 19, 2006 3:59 pm Post subject: |
|
|
Irgendwie ist es doch seltsam dass es dafür nicht längst ausgereifte Lösungen gibt. Im Prinzip müsste doch das Problem überall dort auftreten, wo mittelmäßig viele Rechner in einem Netz zusammen arbeiten und gemountete Home-Verzeichnisse haben. Oder sorgt einfach der niedrige Festplatten-Preis dafür dass man lieber zwei drei Fileserver hinstellt anstatt eine eher komplexe P2P-Lösung aufzusetzen?
_________________
"You may say I'm a dreamer, but I'm not the only one." |
|
| Back to top |
|
|
Freiburg
Guru
Joined: 19 Jun 2004
Posts: 504
Location: Freiburg
|
| Posted: Mon Jun 19, 2006 4:52 pm Post subject: |
|
|
| komplex ist immer auch fehleranfällig und oder teuer. Mittlerweile sind die Festplattenpreise wie du schon gesagt hast so billig das sich etwas so komplexes nicht lohnt und wo es sich lohnen würde ist man eher konservativ. Zudem wird das ganze wirklich interessant im richtig großen Stil und da gibt es ja Lösungen sieht gfs... |
|
| Back to top |
|
|
Haldir
Guru
Joined: 27 Sep 2002
Posts: 546
|
| Posted: Mon Jun 19, 2006 5:37 pm Post subject: |
|
|
| Freiburg wrote: | | Den selben Effekt hättest du dann aber auch wenn du in jedem Knoten speichern würdest auf welchen Nodes die Daten zu finden sind. Außerdem glaub ich nicht das ein Binärsuchbaum die richtige Datenstruktur für sowas ist. Es geht ja mehr darum das jeder weiß wo die Teile einer Datei liegen, da würde eine Hashtabelle eher passen... |
Ist eine Frage der Philosophie bzw. der Sicherheitseinstellung dahinter, es sollte nie jeder Knoten speichern auf welchen anderen Knoten seine Datei ist, aus den beschriebenen hashing problemen
Aber du hast recht für eine lan lösung ist die Hashmap sicher besser. |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Mon Jun 19, 2006 5:42 pm Post subject: |
|
|
Mit einem zentralen Dateiserver ist das regelmäßige Backup auf zum Beispiel Bandlaufwerke deutlich einfacher, Zugriffsrechte lassen sich einfacher verwalten, Verschlüsselung der gespeicherten Daten ist leichter zu implementieren etc. Außerdem läßt sich dann eine Quota-Regelung besser durchsetzen.
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
supermihi
Guru
Joined: 09 Feb 2005
Posts: 348
|
| Posted: Mon Jun 19, 2006 5:47 pm Post subject: |
|
|
Jau da hast du wohl recht. Ich finde es nur irgendwie traurig diese hunderte von Gigabyte ungenutzt zu lassen.
_________________
"You may say I'm a dreamer, but I'm not the only one." |
|
| Back to top |
|
|
_hephaistos_
Advocate
Joined: 07 Apr 2004
Posts: 2694
Location: salzburg, austria
|
| Posted: Mon Jun 19, 2006 5:55 pm Post subject: |
|
|
so zum mom. status:
das projekt ist, wie slick sagte, nicht tot.
wir haben auch alle unser "normales" leben und gerade wenig zeit.
von AVL trees bin ich abgekommen. tendiere eher zu einem B* tree (gerade im bezug auf den zugriff ist da die performance besser, weil diese für HD zugriffe optimiert sind)
vorerst haben wir mal mit RPC und C angefangen - als "proof of concept".
aber es gab da einige dinge, die wir von anfang an nicht bedacht haben.
daraufhin haben wir eine neue API erzeugt (von nfs abgeschaut) und nun ruht das teil
es gab auch zB probleme was die speicherung der daten angeht. da gab es meinungsverschiedenheiten, zB bei der verfügbarkeit der "nodes" und der redundaten datenhaltung. ich bin (nach wie vor) der meinung, dass man vorerst redudantes halten vermeiden sollte und die nodes eine hohe verfügbarkeit haben sollen....
ein weiterer diskussionspunkt ist: die groß sollen die blöcke sein, die versendet/gespeichert werden? in der endlösung wars schon fast so, dass die gespeicherten attribute (zB id, permissions und ähnliches) mehr speicher brauchten als die blöcke
ein weiteres problem ist, wenn man ein file "in der mitte" ändert. dh: es kann sein, dass blöcke null werden, kleiner werden uvm....
kurz: es ist NICHT SO TRIVIAL wie es ausschaut!!!!!!!!
cheers
_________________
-l: signature: command not found |
|
| Back to top |
|
|
caraboides
Apprentice
Joined: 29 Jun 2004
Posts: 180
Location: Rostock
|
| Posted: Sat Jul 08, 2006 1:36 pm Post subject: |
|
|
http://www.pvfs.org/pvfs2/
Wollt ihr sowas bauen?
CU
_________________
Long live the fighters! |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Mon Aug 27, 2007 2:35 pm Post subject: |
|
|
| Think4UrS11 wrote: | na da fehlt aber dann noch Raid over USB-Stick und Raid over 'various flash media'
schließlich hat so ein Cardreader von Haus aus mindestens 4 Slots die auch parallel bestückt werden können |
Die Jungs scheinen obige Schnapsidee gelesen zu haben ... http://youtube.com/watch?v=1zw8V8g5eT0
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
Keepoer
Apprentice
Joined: 30 Mar 2004
Posts: 293
Location: Zwischen Kassel und Edewecht pendelnd
|
| Posted: Tue Aug 28, 2007 7:55 pm Post subject: |
|
|
Ich finde die Idee einfach nur genial. Das ganze mit ~50 Sticks, bissl hergerichtet und man ist die Attraktion auf jeder LAN Bzw. auch ne Bastelaktion fürs GSC? 
Ich habe aber mal ne inhaltliche Frage: Eigentlich haben die Jungs doch nur ein Raid 15 gebastelt, oder? Mal davon abgesehen, dass ich den Pool einfacher im-/exportieren kann. Im Netz habe ich nichts wirklich aufschlussreiches gefunden... Ein wenig Aufklärungwäre ganz nett... |
|
| Back to top |
|
|
treor
Apprentice
Joined: 03 May 2005
Posts: 174
Location: germany
|
| Posted: Wed Aug 29, 2007 10:34 am Post subject: |
|
|
| slick wrote: | Soo... ich habe mir nochmal Gedanken gemacht wie so ein P2P-Filesystem aussehen müßte. Ich versuchs mal zu beschreiben, evt. ist ja jemand mit ausreichend Programmierkenntnissen von der Idee begeistert:
Es gibt eine Software, im folgenden als Client bezeichnet, die folgendes macht:
- Dateien werden auf Client geschrieben
- Client zerlegt diese Daten in Blöcke bestimmter Größe
- jeder Block erhält noch Metainformationen (von welcher Datei, welche Block-Nr, eindeutige ID)
- Client macht für jeden Block den er hat:
-- Broadcast ins Netz welcher Client denn noch den Block mit Id: X hat
-- Clients ohne den Block X melden sich und melden auch ihren "Status" (z.B. Y% belegt, Empfang ok...)
-- Client entscheidet nun welcher andere Client am besten geeignet ist (Bandbreite oder Speicherstatus) und
sendet Block an zweiten Client
-- melden sich mehr als 1 Client die den Block schon haben entscheidet der broadcastende Client welcher der Clients den Block löschen kann, weil er braucht nur 2x da zu sein
Wenn das alle Clients machen, sollten die Blöcke redundant im Netz liegen und bei Wegfall eines Clients würde sich das Netz selbst neu syncronisieren. Die effektive Nutzbarkeit wäre bei 50% der Gesamtgröße der Ressourcen in Netz minus evt. zusätzliche Redundanzen... |
kurz meine gedanken dazu:
du wirst entweder einen zentralen-server brauchen der eine list führt welcher client welchen block hat
oder jeder client muss diese liste für jeden client führen.
sonnst gibt es bei wegfall eines clients das problem das keiner der anderen weiß welche blöcke jetzt fehlen -> entweder wird die liste geführt oder die clients müssen anfangen für _jeden_ block zu fragen wer den hat -> massiver broadcast verkehr.
und was passiert wenn in der reorganisations-phase noch ein client wegbricht? (gefahr besteht bei geführt liste auch aber da ist die reorganisations-phase kürzer)
wie wird das bei einem SAN gemacht? da stört es ja auch nicht wenn eine komponente ausfällt.
könnte mir vorstellen das nen SAN da in ne ähnliche richtung geht
[edit]
arg. seite 2 und seite 3 übersehen.
+quote eingefügt
[\edit] |
|
| Back to top |
|
|
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Wed Aug 29, 2007 12:10 pm Post subject: |
|
|
| Quote: | | du wirst entweder einen zentralen-server brauchen der eine list führt welcher client welchen block hat |
Das könnte man auch über eine Distributed Hash Tabelle machen. Für ein kleines Netzwerk allerdings übertrieben
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
sschlueter
Guru
Joined: 26 Jul 2002
Posts: 578
Location: Dortmund, Germany
|
|
| Back to top |
|
|
|
Deutsches Forum (German) 
