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

## slick

Also ich meine damit etwas wie ein Mischung zwischen NFS und Bittorent, d.h. jeder Cleint stellt etwas Speicherplatz zur Verfügung und damit wird ein LAN-weites Dateisystem geschaffen in dem die Daten quasi über alle Clients verteilt werden, evt. mit gewisser Redundanz. (Vergleichbar in gewisser Weise mit einem RAID5)

Gibt es sowas?

(Hintergrund: Ich habe mehrere Rechner im LAN und würde gern deren freien Gesamt-Speicherplatz effektiv ausnutzen.)

EDIT: -[OT]

*edit - Think4UrS11* verschoben ins Diskussionsforum; keine SupportfrageLast edited by slick on Mon Jun 06, 2005 6:05 pm; edited 1 time in total

----------

## schachti

Wenn ich mich recht erinnere, arbeitet AFS mit großen Caches auf den Clients, vielleicht geht das so ungefähr in Deine Richtung?

----------

## Archaon

Vielleicht suchts du sowas wie Direct Connect?

----------

## slick

Also hinter das Prinzip von Direct Connect bin ich noch nicht ganz gestiegen, aber es schaut so aus als wäre es eine "normale" Tauschbörse...

Ums nochmal zu präzisieren:

Also ich suche was mit dem ich folgendes machen könnte. Reine Wunschvorstellung, aber evt. kennt ja jemand was in der Richtung. Ich beschreibe das mal als Client-Server-Lösung, so kann mans besser beschreiben

- jeder teilnehmende Client kann einstellen wieviel Speicher er freigibt

- die Server faßt diesen Speicher zu einer großer "Ressource" zusammen (optimal: mountbar)

- kopiert man Daten auf diese Ressource werden diese in Häppchen auf den Clients abgelegt

- durch entfernen eines Clients lassen sich die Daten immernoch lesen... d.h. die Häppchen werden je auf mehrere Clients verteilt...

(Eine, rein theoretische(!) Idee die ich dazu hatte war auch noch auf jedem Client einen NFS-Server zu starten und dann darin ein Containerfile abzulegen, dieses auf dem Server mounten und alle Containerfiles irgendwie als irgendein RAID verknüpfen.)

Soweit zumindest die Theorie  :Wink: 

Nochmal zum Hintergrund: Ich habe ca. 5 Maschinen mit je 40GB freien Platz, d.h. 200GB gesamt... durch 50% Abzug für Redundanzen wären das immernoch 100GB... so könnte ich mir einen Fileserver sparen... wenn denn die Rechner irgendwie in einem Speichercluster zusammenarbeiten würden.

----------

## Hilefoks

Moin,

schöne Idee! Ich habe mal was von einem GnutellaFS gelesen. Könnte sein das das in die Richtung geht. Leider habe ich keine Idee wo ich das gelesen habe - aber Google wird schon helfen.  :Wink: 

Mfg Hilefoks

----------

## reptile

eine lösung habe ich nicht, aber direct connect ist definitiv nicht das, was du suchst. ist, wie du sagtest, eine 'normale' tauschbörse.

----------

## slick

 *Hilefoks wrote:*   

> ...! Ich habe mal was von einem GnutellaFS gelesen...

 

Ist auch nur ein etwas anderer Gnutella-Client... 

 *http://lufs.sourceforge.net/lufs/fs.html wrote:*   

> Forget everything you knew about file sharing clients. This is a glimpse of the future...
> 
> You mount a gnetfs in ~/gnet. You wait a couple of minutes so it can establish its peer connections. You start a search by creating a subdirectory of SEARCH: mkdir ~/gnet/SEARCH/metallica mp3. You wait a few seconds for the results to accumulate. The you chdir to SEARCH/metallica mp3 and try a ls: surprise  the files are there! You shoot up mpg123 and enjoy... You are happy.
> 
> Sounds too good to be true? Well, it's here... 
> ...

 

----------

## slick

 *slick wrote:*   

> Eine, rein theoretische(!) Idee die ich dazu hatte war auch noch auf jedem Client einen NFS-Server zu starten und dann darin ein Containerfile abzulegen, dieses auf dem Server mounten und alle Containerfiles irgendwie als irgendein RAID verknüpfen.

 

Habe ich jetzt mal ausprobiert. Man muß die Containerdateien von den NFS-Servern zwar erstmal mit losetup behandeln, aber dann funktioniert das tatsächlich. RAID5 über Netzwerk... KRASS.... das sind die Gründe warum ich Linux so mag...  :Very Happy:   :Shocked:   :Laughing: 

----------

## the-pugnacity

wenn du jetzt noch beschreibst wie du das mit NFS gemacht hast währe ich glücklich....son kleines howto wäre fein

----------

## slick

Jetzt im Wiki, siehe: http://de.gentoo-wiki.com/HOWTO_RAID_over_NFS

Ok, kleines RAID-over-NFS-HowTo... 

(in english)

 :Exclamation:   Nur für Leute die wissen was sie tun und nicht für den produktiven Einsatz.

Zuerst am "Client" einen NFS-Server aufsetzen (Das auf jedem "Client" machen)

```
emerge nfs-utils
```

Dann dort eine Freigabe schaffen und diese in /etc/exports eintragen (ACHTUNG: Freigabe mit root-Rechten, ggf. anpassen, hier fürs ganze LAN)

```
mkdir /freigabe

echo "/freigabe 192.168.0.0/24(rw,async,no_root_squash)" >> /etc/exports

/etc/init.d/nfs start
```

Die Containerdateien müssen bei RAID5 gleich groß sein, für andere RAID-Arten weiß ich es nicht genau.. bitte Suchmaschinen fragen...

Am "Server" installieren:

```
emerge nfs-utils raidtools

/etc/init.d/nfs start

```

 Auch muß ebenso die jeweilige RAID-Art im Kernel sein.

Jetzt am "Server" Mountpoints anlegen und die entfernten NFS-Freigaben mounten.

```
mkdir /mnt/client1

mkdir /mnt/client2

mkdir /mnt/client3

mount host1:/freigabe /mnt/client1

mount host2:/freigabe /mnt/client2

mount host3:/freigabe /mnt/client3
```

Dann auf den Freigaben die Containerdateien anlegen... (hier 3x500MB)

```
dd if=/dev/zero of=/mnt/client1/container bs=1M count=500

dd if=/dev/zero of=/mnt/client2/container bs=1M count=500

dd if=/dev/zero of=/mnt/client3/container bs=1M count=500
```

Die Containerdateien über ein Loopback-Device legen

```
losetup /dev/loop1 /mnt/client1/container

losetup /dev/loop2 /mnt/client2/container

losetup /dev/loop3 /mnt/client3/container
```

Dann /etc/raidtab entsprechend erstellen... hier ein passendes Beispiel:

```
raiddev /dev/md0

    raid-level                  5

    nr-raid-disks               3

    nr-spare-disks              0

    persistent-superblock       1

    parity-algorithm            left-symmetric

    chunk-size                  128

    device                      /dev/loop1

    raid-disk                   0

    device                      /dev/loop2

    raid-disk                   1

    device                      /dev/loop3

    raid-disk                   2
```

Dann den Raid erzeugen und zuschauen bis er sich fertig aufgebaut hat:

```
mkraid /dev/md0

watch cat /proc/mdstat
```

Dann Raid formatieren und mounten:

```
mke2fs /dev/md0

mount /dev/md0 /mountpoint
```

Ich übernehme keine Gewähr für verlorene Daten, das ist rein experimentell!Last edited by slick on Sat Aug 12, 2006 6:32 pm; edited 2 times in total

----------

## the-pugnacity

danke dafür. ich überleg mir nur grad wie ein passendes init script aussieht, weil im normalfall wird ja erst raid ausgeführt und dann mount aber das geht ja nicht da für raidtab ja erst nfs gemounted werden muss.....

----------

## slick

Ich überlege wie ich diese Erkenntnis am besten nutzen kann. Wahrscheinlich nicht so sehr, weil sich die Größe des freien Speichers auf allen Rechner unterscheidet, daher käme nur ein Raid0 in Frage was mir zu unsicher ist und auch keine Redundanzen bietet. 

Just4Info hier mal das Ergebnis von tiotest, alle 3 Containerdateien über NFS, RAID5 wie oben beschreiben, 100MBit LAN

```
# tiotest

Tiotest results for 4 concurrent io threads:

,----------------------------------------------------------------------.

| Item                  | Time     | Rate         | Usr CPU  | Sys CPU |

+-----------------------+----------+--------------+----------+---------+

| Write          40 MBs |    6.3 s |   6.308 MB/s |   0.2 %  |  13.7 % |

| Random Write   16 MBs |    6.0 s |   2.602 MB/s |   0.1 %  |   4.4 % |

| Read           40 MBs |    0.1 s | 268.125 MB/s |   6.7 %  |  92.5 % |

| Random Read    16 MBs |    0.1 s | 244.500 MB/s |   6.3 %  |  89.2 % |

`----------------------------------------------------------------------'

Tiotest latency results:

,-------------------------------------------------------------------------.

| Item         | Average latency | Maximum latency | % >2 sec | % >10 sec |

+--------------+-----------------+-----------------+----------+-----------+

| Write        |        0.127 ms |      327.244 ms |  0.00000 |   0.00000 |

| Random Write |        0.107 ms |       66.123 ms |  0.00000 |   0.00000 |

| Read         |        0.014 ms |        0.795 ms |  0.00000 |   0.00000 |

| Random Read  |        0.014 ms |        1.582 ms |  0.00000 |   0.00000 |

|--------------+-----------------+-----------------+----------+-----------|

| Total        |        0.068 ms |      327.244 ms |  0.00000 |   0.00000 |

`--------------+-----------------+-----------------+----------+-----------'
```

----------

## slick

 *slick wrote:*   

> Also ich meine damit etwas wie ein Mischung zwischen NFS und Bittorent, d.h. jeder Cleint stellt etwas Speicherplatz zur Verfügung und damit wird ein LAN-weites Dateisystem geschaffen in dem die Daten quasi über alle Clients verteilt werden, evt. mit gewisser Redundanz. (Vergleichbar in gewisser Weise mit einem RAID5)

 

Hmm.. freenet macht das so ähnlich, nur müßte man die Verschlüsselung weglassen und das ganze mountbar machen... Gibts ein java-guru hier der freenet kennt und der was dazu sagen könnte.

----------

## think4urs11

Hi,

so spontan fallen mir da vier Stück ein die in die Richtung gehen:

Coda  :Arrow:  http://coda.cs.cmu.edu/

OpenAFS  :Arrow:  http://www.openafs.org/

InterMezzo  :Arrow:  http://www.inter-mezzo.org/

Microsoft DFS  :Arrow:  http://www.microsoft.com/ntserver/nts/downloads/winfeatures/NTSDistrFile/AdminGuide.asp :Rolling Eyes: 

Wobei man sagen muß dein Raid-5 über NFS hat auch einen gewissen perversen Charme  :Twisted Evil: 

HTH

T.

----------

## dakjo

@slick Ich wollt nur mal sagen. GEiL Ey! Typ! Das Krass das so mit nfs raid.

----------

## slick

Also habs grad mal nochmal in Ruhe ausprobiert... also RAID-over-NFS ist nicht für den realistischen Betrieb geeignet. Fällt ein Client während des Betriebs weg ist schreiben und lesen unmöglich (lesen nur was noch so im Cache ist). Der zugreifende Prozess "friert" dann ein. Fehlt ein Client schon beim Start des RAIDs läßt sich dieses gar nicht erst starten... also einen experimentellen Einsatz für das kleine Home-Lan sehe ich da nur gegeben wenn die Clients 100% verfügbar sind was unter normalen Unständen zwar theoretisch möglich ist, aber wichtige Daten würde ich darauf nicht verwetten.

----------

## 76062563

Egal, allein die Idee find ich super!

----------

## slick

Hmm... ich mal mir grad so andere witzige Szenarien aus... also RAID-over-Samba oder RAID-over-SHFS sollten damit auch möglich sein  :Very Happy:   :Twisted Evil: 

----------

## think4urs11

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

----------

## spielc

 *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

 

LOL keine bloede idee  :Shocked: 

----------

## the-pugnacity

irgend wo hab ich mal in den weiten des netz es nen disketten raid gefunden.... 20 disks arbeiten zusammen  :Cool:   :Cool: 

----------

## M@rio

Irgendwie steckt in dem Konzept ein Denkfehler.

Schließlich müssen alle Daten auf allen Workstations vorhanden sein. Bei Raid-5 z.b. könnte man 1 Client abschalten, aber schon beim 2. abgeschaltenen Client wären die Daten nicht mehr komplett. 

Das ist bei P2P ja auch so. Wenn nur 1 Block fehlt, ist die restliche Datei wertlos. Während man bei P2P Anwendungen aber einfach mal ein paar Stunden/Tage/Wochen wartet bis der fehlende Block möglicherweise doch noch von irgendwem ge-shared wird, will wohl keiner ein paar Stunden auf seine Daten im LAN warten.

Also bliebe im Endeffekt nur die Möglichkeit die Daten einfach per rsync auf alle Clients zu verteilen. Was zwar sehr redundant wäre, aber auch heftige Platzverschwendung.

----------

## slick

Ich denke es kommt darauf an wie man es betrachtet. Das RAID-over-LAN nicht praxistauglich ist schrieb ich ja bereits, das war nur ein "Nebenprodukt" der Überlegungen... aber einen P2P Lösung könnte ich mir durchaus vorstellen. Wenn man die Daten wie einem einem RAID verteilen würde und das jeweils zusätzlich noch redundant, könnte schon mehr als 1 Client wegfallen. Das sollte das Cluster dann merken und diese Daten raid-ähnlich neu berechnen und auf die bleibenden Maschinen verteilen. Geht der Client wieder ans Netz werden die Daten wieder neu auf ihn verteilt. Es geht ja auch nicht darum die Gesamtanzahl der freien Bytes direkt zu nutzen, bei einem wie oben beschriebenen Verfahren wären wohl so ca. 1/3 - 1/2 effektiv nutzbar, was aber bei einer gewissen Anzahl Clients schon Sinn machen kann. Außerdem geht es nicht darum eine High-Speed-Ressource zu haben. Ich stelle mir das eher als Ablage für Sachen die man nicht so häufig benötigt... z.B. Distfiles, Images von irgendwelchen CDs o.ä.

----------

## limes

Linux gehört eindeutig verboten  :Razz: 

----------

## slick

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...

----------

## _hephaistos_

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

Moin, *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:

 

Die Idee finde ich wirklich gut! 

Allerdings finde ich es ebenso wichtig das die "Shared-Files" zu mounten sind - also so wie eine SMB-Freigabe. Ich denke soetwas könnte leicht(er) mit FUSE implementieren. Natürlich müsste es aber auch Client-Software für andere OS geben.

 *slick wrote:*   

> - 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...)

 

Broadcast = BÖSE!

Mfg HilefoksLast edited by Hilefoks on Mon Aug 15, 2005 7:26 pm; edited 1 time in total

----------

## slick

 *hephaistos6 wrote:*   

> also ein "Client" ist bei dir eigentlih auch ein Server oder? dh: hohe Verfügbarkeit zu erwarten?

 

Jeder Client ist auch Server, die Verfügbarkeit sehe ich im engen Zusammenhang mit der Größes des Netzes und der Übertragungsraten darin. Ab einer gewissen Größe sollte es unperformant werden, es sei denn es organisieren sich darin "logische" Cluster.

 *hephaistos6 wrote:*   

> und wer verwaltet nun die IDs? dh: es müsste ja einen "Masterserver" geben, der Infos über ALLE Dateien (mit IDs) hat.

 

Einen zentralen Server sehe ich bisher nicht. Die Pakete werden auf Abruf aus den Netz angefordert. Jeder Client sollte aber einen Cache vorhalten (z.B. durch Mitlesen der Broadcasts der anderen Clients) um z.B. von seiner Maschine häufig gelesene Dateien schneller zu finden.

 *Hilefoks wrote:*   

> Broadcast = BÖSE!

 

War meine erste Idee als Laie  :Wink: 

----------

## _hephaistos_

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

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_

jo, hast recht.

es sollte eine art hashfunktion für die berechnung der ID geben.

dh: dateiname+md5(content)+filetype+blocknummer irgendwie verhashed  :Smile: 

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

----------

## slick

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  :Wink: 

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

----------

## Hilefoks

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.

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!

----------

## slick

split ?

 *Quote:*   

> falls was aus dem Projekt wird, hab ich allerdings einen Namensvorschlag= genfs ! 

 

Hmm.. also als Schöpfer der Idee will ich da was mitreden... momentan liegt aber noch kein besserer Vorschlag an... das Baby wird erst getauft wenns geboren ist  :Wink: 

----------

## the-pugnacity

geht eventl. GFS von dem roten Hut in die Richtung??

http://www.redhat.com/software/rha/gfs/

----------

## m.b.j.

 *slick wrote:*   

> split ?
> 
>  *Quote:*   falls was aus dem Projekt wird, hab ich allerdings einen Namensvorschlag= genfs !  
> 
> Hmm.. also als Schöpfer der Idee will ich da was mitreden... momentan liegt aber noch kein besserer Vorschlag an... das Baby wird erst getauft wenns geboren ist 

 

Der Post, sollte ja eher jemanden ermuntern mir zu sagen wie ich Dateien in Chunks aufteilen, kann, dann hätte ich etwas rumgetestet... Der Namensvorschlag war ja nicht Ernst gemeint!

EDIT, ich bastele gerade was mit split, mal schaun, obs was bringt!

----------

## slick

 *the-pugnacity wrote:*   

> geht eventl. GFS von dem roten Hut in die Richtung??

 

In die Richtung ja, aber ich bin zu blöd um zu beurteilen ob es das ist was ich suche. Ziel des gesuchten Fs ist eher das Ausnutzen der verteilten freien Ressourcen in kleinen bis mittleren LANs (ohne den Sicherheitsaspekt jetzt genauer zu betrachten) und nicht als High-Speed-FS in Serverfarmen.

----------

## m.b.j.

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

```
#!/usr/bin/ruby

require 'digest/sha1'

BLOCKLEN=64

Dir.chdir("files");

dir=Dir.new(".");

array=Array.new

dir.each { |entry|

        path=dir.path + "/" + entry.to_s 

        if File.file?(path)

         size=File.size(path)

         curfile=File.new(path)

         mod=size%BLOCKLEN

         start=0

         0.step(size-mod,BLOCKLEN) { |i| 

          buf=curfile.read(BLOCKLEN)

          hash=Digest::SHA1.hexdigest(buf) if buf

          array << hash;

          }

        end

        }

puts array.length

array.uniq!

puts array.length
```

Sicherlich ist der nicht perfeckt (Nicht wirklich die ganze Datei wird gelesen, es bleibt immer nochwas von >BLOCKLEN übrig..), aber ich hab mir ein Test Verzeichniss mit den Dateien 

```
 alsa-driver-1.0.9rc2.tar.bz2

 alsa-driver-1.0.9rc3.tar.bz2

```

 erstellt, und das Script dafüberlaufen lassen...

Also wie im Thread angesprochene "Doch fast gleiche Dateien"

Erst bei einer Blockgröße von 64, was 64byte entspricht (?)  konnte ich feststellen, dass es identische Blöcke gab... (die dann den gleichen Hash erzeugen der dann aus dem Hash-Array gelöcht wurde), aber seht doch selbst:

```

# ruby test.rb

141466

141464

```

Mir ist klar, das der code billig ist, doch würde ich mir gedanken machen, ob man gzip komprimierte Dateien durch so ein Netzwerkdateisystem überhaupt noch verkleinern kann...

Oder hab ich einen (Denk)Fehler gemacht?

----------

## _hephaistos_

@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  :Smile: 

cheers

----------

## m.b.j.

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*

----------

## _hephaistos_

 *m.b.j. wrote:*   

> 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*

 

 :Smile:  naja kompression kann man ja "optional" machen.

----------

## slick

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

So, wir hatten ja auf dem Usertreffen die Gelegenheit das ganze mal bei einem (oder waren es mehr  :Wink: ) 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_

 *slick wrote:*   

> oder waren es mehr 

 

naja, immerhin waren es 6 sorten (augustiner, jever[hell/dunkel], kölsch, alt, bit) - die man alle mal probiert hatte

 *Quote:*   

> _hephaistos_ oder Hilefoks bringst du uns nochmal auf Stand?

 

ich denke das machen wir "intern" - nach dem motto: "du sollst den tag nicht vor dem abend loben"

cu

----------

## ChrisM87

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.  :Smile: 

ChrisM

----------

## supermihi

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?

----------

## Haldir

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  :Wink: 

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

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

@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

 *supermihi wrote:*   

> der Thread ist schon alt, aber ich suche gerade genau so etwas

 

MapFS? Scheint wohl auch sowas in der Art zu machen, kann ich allerdings nicht korrekt beurteilen. Anscheinend ohne Redundanz.

Just Info, das in diesem Thread erdachte Projekt (distfs, wie wir es vorläufig genannt haben) ist noch nicht tot. Ein paar wenige Leute arbeiten daran... momentan ruht es eher. Wird aber wohl noch einige Zeit brauchen bis es sichtbare Ergebnisse geben wird. Interessierte sollten das GSC2006 nutzen um sich darüber zu informieren, da dort alle Beteidigten zu finden sein werden.

----------

## manuels

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

----------

## Haldir

 *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  :Wink: 

----------

## Freiburg

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...

----------

## supermihi

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?

----------

## Freiburg

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...

----------

## Haldir

 *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  :Wink: 

Aber du hast recht für eine lan lösung ist die Hashmap sicher besser.

----------

## schachti

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.

----------

## supermihi

Jau da hast du wohl recht. Ich finde es nur irgendwie traurig diese hunderte von Gigabyte ungenutzt zu lassen.

----------

## _hephaistos_

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  :Wink: 

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  :Wink: 

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

----------

## caraboides

http://www.pvfs.org/pvfs2/

Wollt ihr sowas bauen?

CU

----------

## think4urs11

 *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  :Wink: 

----------

## Keepoer

 *Think4UrS11 wrote:*   

> Die Jungs scheinen obige Schnapsidee gelesen zu haben ... http://youtube.com/watch?v=1zw8V8g5eT0 

 

Ich finde die Idee einfach nur genial. Das ganze mit ~50 Sticks, bissl hergerichtet und man ist die Attraktion auf jeder LAN  :Wink:  Bzw. auch ne Bastelaktion fürs GSC?  :Laughing: 

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...

----------

## treor

 *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
> ...

 

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]

----------

## manuels

 *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

----------

## sschlueter

Hab auch noch ein Projekt gefunden, dass hier thematisch reinpasst: http://www.danga.com/mogilefs/

----------

