GlusterFS

kai_001

Well-Known Member
Hi,

ich habe mal die aktuelle Version auf 2 FreeBSD Servern und installiert ( amd64, 7.2-RELEASE ).

Mounten von einem PCBSD ( 7.1-STABLE, i386 ) geht auch. Aber schreiben gibt Probleme mit folgender Erklärung der GlusterFS Maillingliste ...

Some known issues and pending activities stalled for upcoming releases.
Distribute translator: uses 64bit inode numbers, as FreeBSD doesn't support 64bit inodes. Distribute is seen to not work on FreeBSD ( Klick ).

Ich habe dazu speziell bei freebsd.org nichts weiter gefunden, könnt Ihr mir dazu was sagen? Eventuell für die Server DragonFly mit HAMMER nutzen?

Ich wollte ungern ein Linux für Storage einsetzen ... :confused:

Danke und Gruß
Kai
 
Cool, bei dir geht das erst mal grundsätzlich auf FBSD 7.2/amd64! Auf Solaris 10 raucht bei mir der Server ab sobald sich ein Client (in dem Fall OS X) verbindet.
 
Hm...Cluster-Filesystem ist in HammerFS doch noch gar nicht integriert, sondern wird erst noch kommen? Oder hat sich da mittlerweile schon was getan?
 
Cluster != Gluster

Oder was meinst Du?

Gruß
Kai


PS: GlusterFS setzt auf vorhandene Filesystem auf, glusterfs.org
 
Von Hauptseite glusterfs.org: "GlusterFS is a cluster file-system"

Vom ersten Post des Threaderstellers: "ich habe mal die aktuelle Version auf 2 FreeBSD Servern und installiert "

Sollte ich das trotz all diesem Missverstanden haben, möge ich das entschuldigen :-)
 
Hi,

"Some known issues and pending activities stalled for upcoming releases.
Distribute translator: uses 64bit inode numbers, as FreeBSD doesn't support 64bit inodes. Distribute is seen to not work on FreeBSD"

Daher die Fragen wegen DragonFly und HAMMER, da dieses wohl 64Bit inode numbers nutzt ...

Also glusterfsd als Daemon auf DragonFly mit HAMMER als FS laufen lassen.

Gruß
Kai
 
UFS2 nutzt 256 Bit lange Inodes. Was die GlusterFS Entwickler sagen möchten ist, dass FreeBSD im VFS den Datentyp "ino_t" nach wie vor auf 32 Bit hat. Oder anders gesagt, das zugrunde liegende Dateisystem ist völlig egal.
 
UFS2 nutzt 256 Bit lange Inodes. Was die GlusterFS Entwickler sagen möchten ist, dass FreeBSD im VFS den Datentyp "ino_t" nach wie vor auf 32 Bit hat. Oder anders gesagt, das zugrunde liegende Dateisystem ist völlig egal.

Hmm, ich hab dass bissel anders interpretiert ... dadurch, dass FreeBSD ino_t auf 32Bit hat, funzt es eben nicht? Kapier ich nicht ...


Kai
 
Die Inodes an sich sind ja etwas völlig dateisystemabhängiges, was sich auf der Platte befindet. Diese sieht GlusterFS gar nicht, er kann allenfalls indirekt auf sie zugreifen, indem er über den Dateisystemtreiber geht. Was GlusterFS sieht ist ihre Repräsentation im VFS, also eine Abstraktion innerhalb des Kernels. Und an dieser Stelle konmmt ino_ ins Spiel. Hier werden die Inodes als laufende Nummern gespeichert, sozusagen. ZFS und UFS2 ist es auf Grund ihrer Struktur egal, dass ino_t nur 32 Bit lang ist. Auch wenn intern 64 Bit oder sogar 128 Bit lange Integer genutzt werden, kommen sie auf der Ebene mit 32 Bit locker aus. Neuere Dateisysteme aber, wie zum Beispiel GlusterFS oder HAMMER, kommen dort nicht mehr aus, sie brauchen 64 Bit länge. Sonst bekommen sie ihre Adressen nicht untergebracht.

Warum nun nicht einfach ino_t auf 64 Bit erhöhen? Es gab das Diskussionen, Flamewars und sogar Patches zu. Das Problem ist einmal Posix. Dort steht klar drin, dass ino_t ein atomarer Typ zu sein hat. Dann ist da NFS. NFS verlangt 32 Bit, mehr würde einen ekligen Hack benötigen. Und das vielleicht wichtigste Argument ist fehlender Bedarf. Solange FreeBSD kein Dateisystem hat, welches ein 64 Bit ino_t benötigt, ist es reichlich sinnlos es einzubauen...

Für GlusterFS wurde nun dieser Hack vorgeschlagen: http://lists.freebsd.org/pipermail/freebsd-fs/2009-June/006402.html Er macht nichts anderes, als ino_t einfach 64 Bit lang zu machen, zumindest in seiner externen Repräsentation.
 
Ok, verstanden ... ich möchte unbedingt GlusterFS ausprobieren, da es einfach zu wenig Alternativen für FreeBSD gibt.

Ich schaue mir den Hack mal an und teste damit.


Danke Dir schonmal!

Gruß
Kai
 
Hmm,

habe mal versucht Kernel neu zu bauen, aber diese kleine Änderung zieht sich durchs ganze System ...

Dann werde ich mal schauen, inwieweit DF BSD damit funktioniert.

Danke für die Hilfe!

Kai
 
Back
Top