Suche Linux und OS X kompatibles Dateisystem

Pingu schrieb:
Weil wenn FUD verbreitet wird, kann ich nicht anders.

Aha. Schön. Dann brauche ich ja nicht weiter reden...

Aber trotzdem noch ein paar Sachen:

1. "HFS+" ist NICHT "HFS mit Journal"

2. Wenn man auf ein veraltetes Dateisystem ein Journal "draufklatscht", heißt das nicht, dass das "neue" Dateisystem jetzt auf einmal hochmodern ist.

3. OK, wenn ihr meint ext2 sei besser, dann will ich das akzeptieren...
Meine Erfahrungen sind zwar durch die Bank anders, aber naja. Meine Meinung zählt hier ja wohl nicht.

edit:
Sollen mich deine Links in irgend einer Form "beeindrucken", oder was willst du damit erreichen?
 
Zuletzt bearbeitet:
-Nuke- schrieb:
2. Wenn man auf ein veraltetes Dateisystem ein Journal "draufklatscht", heißt das nicht, dass das "neue" Dateisystem jetzt auf einmal hochmodern ist.

ext3 ist ja auch nicht ext2 plus Journal. Das ist EIN Feature von vielen. Du leitest deine Annahme irrtümlich aus der Abwärtskompatibilität ab.

-Nuke- schrieb:
3. OK, wenn ihr meint ext2 sei besser, dann will ich das akzeptieren...

Eben das hat ja auch niemand gesagt. Filesystem1 ist niemals überall besser als Filesystem2, sonst hätten wir nur noch Filesystem1.

Ich versuche mal zu rekapitulieren:
Der OP sucht ein Filesystem für einen kleinen Internet-Fileserver für seine Kumpels. Das heisst: Seine Filesystem-Performance ist relativ egal, weil die ganze schöne Hardware hinter seinem DSL-Modem Schlange steht und schnarcht.

Wenn er für /boot ext2 nimmt, hat er den Vorteil einer weiterverbreiteten Kompatibilität, falls er mal ein Reparaturtool braucht.

Was er für / nimmt, ist relativ egal, denn der Rechner wird sich sowieso langweilen. Aus der Aussage "egal" würe ich nicht ableiten, er solle ext2 nehmen - das kann er ohne weiteres tun, ohne irgendwas wichtiges zu verlieren - aber warum sollte er? xfs, ext3, jfs oder ReiserFS sind stabil, die Einschränkungen von /boot treffen hier nicht zu, sie können Journaling, also hat er freie Auswahl. Was er nicht nehmen sollte, wäre hfsplus (kein Reparaturtool) oder vfat (keine Attribute).
Natürlich wäre ext3 sinnvoller als ext2 wg. des Journals. So rasend wichtig ist das aber alles nicht (und ein ext2 lässt sich auch nachträglich zum ext3 hochbocken). Nochmal: ext2 wäre kein Problem - würde ich aber trotzdem von abraten.

für "/partition_mit_den_movies" sieht die Welt schon wieder anders aus. Da braucht er eine Mindestgröße, die ext2 wohlmöglich nicht liefern kann. Die Performance auf dieser Platte ist wieder relativ egal, denn wie gesagt: Netzwerk ist der Flaschenhals. Und irgendwelche Sonderfälle wie "viele kleine Dateien werden laufend re-indiziert" treffen hier auch nicht zu - also hat er freie Auswahl: ext3, xfs, jfs, ReiserFS.

Eine tiefergehende Diskussion wäre notwendig, wenn es spezielle Anforderungen gäbe. Ich bin z.B. zu xfs gekommen, weil ich Fonts sammle und sehr viele sehr kleine Dateien immer wieder rumschiebe. Wer Videoschnitt macht, braucht hingegen ein FS mit geringen Latenzzeiten - wohlmöglich tatsächlich ext2. Und wer große Websites hostet, sollte sich mal mit Reiser4 auseinandersetzen, das ist mit vielen kleinen Dateien sehr schnell, und wenn was kaputtgeht, hat man die Daten ja sowieso im Backup.


Bei den Stabilitätsproblemen von ReiserFS muß man sich sowieso fragen, was "echt" ist und was "psychologisch". Reiser hat damals zu früh released, und das hat ein paar Leuten ihre Daten gekostet. Seitdem hört man immer wieder, ReiserFS sei unsicher und instabil, aber so richtig relevant viele "Opfer" findet man auch nicht. Wenn im falschen Moment der Strom ausfällt, ist halt was im Ar...gen, das ist anderswo auch nicht anders. Und ein übereifriger APMd kann genau sowas beim Ausschalten auslösen.

Gruß,
Ratti
 
Pingu schrieb:
Es war nur weil Du gesagt hast, daß Ext2 und Ext3 total veraltet wären im vergleich zu ReiserFS und Reiser4. Nur so als Hinweis: Ext3 kam nach ReiserFS. Da Frage ich mich, wie es veraltet sein kann.
FAT32 wurde nach ext2 veröffentlicht. Nach der Logik müsste ext2 veraltet sein.
Nukes Aussage, die Du oben zitierst, ist völlig korrekt. i-Node-Dateisysteme benutzten im Vergleich zu B-Baum-Dateisystemen veraltete Technologie. Ganz egal, wann sie veröffentlicht worden sind.

ratti schrieb:
ext3 ist ja auch nicht ext2 plus Journal. Das ist EIN Feature von vielen. Du leitest deine Annahme irrtümlich aus der Abwärtskompatibilität ab.
Das ändert aber nichts daran, dass es die i-Node-Technologie verwendet, welche nicht mehr wirklich State-of-the-Art ist.
 
ratti schrieb:
... relativ egal, weil die ganze schöne Hardware hinter seinem DSL-Modem Schlange steht und schnarcht ...

rotfl / scnr
 
._ut schrieb:
Das ändert aber nichts daran, dass es die i-Node-Technologie verwendet, welche nicht mehr wirklich State-of-the-Art ist.

It depends on.

Im Zeitalter der Brennstoffzelle ist ein Dieselmotor veraltet - und trotzdem die beste Lösung für einen Bagger.

Die Dateisysteme haben unterschiedliche Vor- und Nachteile. Die Wahl sollte nicht auf den Technologie-Designpreisträger fallen, sondern auf das FS, das am besten auf das Problem matcht. ext3 schlägt sich z.B. besser als ReiserFS, wenn es um das reparieren schwer beschädigter Dateisysteme geht (Was sich mit Reiser4 gerade ändert).

Ich stehe zu meiner Aussage, daß Otto Normaluser darüber nicht groß nachdenken braucht. Passt alles.

Ich selbst bleibe aber bei xfs. :)

Gruß,
Ratti
 
NicolasX schrieb:
Toll ist Ext2 wirklich net.
also willst du eigentlich keinen Server, sondern ne Mobile Festplatte die an allen Rechnern funktioniert richtig?

NicolasX schrieb:
1. Linux Server aufetzen mit nem SATA software RAID5 Xfs.

2. Netatalk drauf Samba einrichten (user, shares etc.)

3. Den für den Mac User eigerichteten share account auf dem Mac mounten und mit CarbonCopyCloner/Festplatten-Dienstprogramm ein Disk image auf den Server schreiben.

4. Dann kleines Script schreiben, daß das ganze automatisch startet oder per remote rootlogin gestartet werden kann.

klingt interessant. Aber wieso Soft-RAID und keine Karte? Aus Kostengründen? Das mit dem Diskimage verstehe ich als "noch nicht mac-user" noch nicht. Kann ich dann mit dem Image auf den Server zugreifen, als wäre es eine Platte vom Mac?

danke fürs feedback!
 
._ut schrieb:
i-Node-Dateisysteme benutzten im Vergleich zu B-Baum-Dateisystemen veraltete Technologie. Ganz egal, wann sie veröffentlicht worden sind.
Jaein. Im Prinzip sind alle Dateisysteme inode basierend. Denn inode steht für nichts anderes als information node oder auf deutsch einen Knoten (Endpunkt), der Informationen bereit stellt. Der Unterschied liegt darin, wie diese inodes organisiert werden, also sequentiell oder in einem balanced tree kurz B-tree (reiser benutzt eine abgewandelte Struktur genannt B*Tree). Der Aufbau und die Datenhaltung eines balancierten Baumes kann in jedem guten Algorithmen-Buch nachgelesen werden.
Der Unterschied liegt also darin, daß bei einem sequentiellen Aufbau die Anzahl der zukünftig benötigten inodes schon zum Zeitpunkt der Erstellung der Struktur bekannt sein muß. Während dies bei einem balancierten Baum dynamisch angepaßt werden kann.
Deswegen kann Ext2 unter bestimmten Bedingung (die Anforderung eines normalen home users entsprechen diesen meistens) sehr schnell sein, da die Position der Einträge (inodes) sehr einfach berechnet werden kann und beim lesen eines Verzeichnisses in einem Block gelesen werden. Dagegen bei einem balancierten Baum liegen die Daten eben nicht zusammen bzw. bei Schreibzugriffen müssen die Blätter des Baumes entsprechend umgeschrieben werden (ausbalanciert), d.h. es sind mehrere Zugriffe nötig. Wie gut ausbalanciert ein Baum ist, hängt vom Algorithmus ab. Reiser4 soll hier ganz neue Ansätze gehen und hat deswegen entsprechende Geschwindigkeitsvorteile. Der wesentliche Nachteil bei Ext2 ist hierbei, daß entweder bei einer zukleinen Anzahl an erstellten inodes, die inodes ausgehen und man sozusagen nichts mehr speicher kann, obwohl noch genügend Platz auf der Partition frei ist oder, daß zuviel Platz für die inodes verbraucht (verschwendet) wird, denn man gar nicht braucht.
._ut schrieb:
Das ändert aber nichts daran, dass es die i-Node-Technologie verwendet, welche nicht mehr wirklich State-of-the-Art ist.
Dieser generelle Aussage würde ich nicht zustimmen. Denn gerade bei ROM-basierenden Medien machen sequentiell strukturierte Verzeichnisse sehr wohl Sinn, denn man weiß im vorhinein sehr genau wieviel man braucht und die Algorithmen zum Zugriff sind sehr viel einfacher zu implementieren als für balancierte baumartige Verzeichnisse. Für den normalen Heimanwender ist es in den meisten Fällen eigentlich fast egal. Für File-Server-Anwendungen stimme ich dieser Aussage zu.

Um noch etwas zu ursprünglichen Frage beizutragen: hier gibt es eine Information über alle Verzeichnissysteme, die von Mac OS X unterstützt werden: http://www.kernelthread.com/mac/osx/arch_fs.html

Pingu
 
Zuletzt bearbeitet von einem Moderator:
catvarlog schrieb:
klingt interessant. Aber wieso Soft-RAID und keine Karte? Aus Kostengründen? Das mit dem Diskimage verstehe ich als "noch nicht mac-user" noch nicht. Kann ich dann mit dem Image auf den Server zugreifen, als wäre es eine Platte vom Mac?

Hi,

du kannst als Admin unter OSX vom laufenden System ein Disk Image erstellen (somit werden auch die versteckten Ordner und Dateien gesichert). Von diesem Image kannst du auch das System nach nem z.B. HD Crash wieder Zurück-Sichern. Das ganze kann auch noch komprimiert werden um Platz zu sparen.

Right you are, du kannst das DI vom Server auf dem Mac mounten, als wäre es ne Platte. Dazu bietet Festplatten-Dienstprogramm sogar noch ne Restore-Funktion, also ne runde Sache.

Klar kannst du ein Hardware RAID5 (Karten/Controller basiert) verwenden (mit Controllern von 3ware hatte ich unter Linux noch nie Probleme).

Wenn du das so aufbaust, kommst du nicht in die Verlegenheit das Dateisystem auf dem Client mounten zu müssen, weder auf dem Mac (durch Netatalk) noch auf dem PC(durch SAMBA).

Gruß

Nicolas
 
Zuletzt bearbeitet:
NicolasX schrieb:
Hi,
du kannst als Admin unter OSX vom laufenden System ein Disk Image erstellen (somit werden auch die versteckten Ordner und Dateien gesichert). Von diesem Image kannst du auch das System nach nem z.B. HD Crash wieder Zurück-Sichern. Das ganze kann auch noch komprimiert werden um Platz zu sparen.

aha! ich lerne dazu. dann könnte ich also z.B.

a.) alle systemrelevanten dateien (z.B. das OS, Programme etc.) als propriäteres diskimage sichern und ein gecraschtes OS-X system ggf. restaurieren

b.) und die eigenen dateien der user (z.B. PSD-Dateien, Quelltexte, Word-Dateien etc.) per rsync 1:1 sichern, damit man auch ohne mac auf die datei zugreifen kann. das setzt allerdings vorraus, dass man auch daten aus dem image exludieren kann. oder man wird redundant :(

kann man eigentlich auch lesend via Linux auf das OS X-Discimage zugreifen? wohl eher nicht, oder?

im moment tendiere ich in punkto lösung eher zu einem dedizierten server mit externem RAID und samba/netatak. das ist anscheinend die beste wahl.

meine alternative war der einsatz von externen firewire-platten. da es allerdings wohl kein stabiles und sauberes filesystem für die gemeinsame nutzung durch OS-X und linux gibt, erscheint der dedizierte linux-server als bessere lösung, wenn überwiegend linux-rechner und nur ein Mac OS X-System im Einsatz sind.
sollte der OS-X dann nämlich ausfallen, wäre das der worst-case, den ich eigentlich verhindern möchte.


noch mal vielen dank für dein und euer feedback!
 
Zuletzt bearbeitet:
._ut schrieb:
Das war doch die Anforderung bei der Ursprungsfrage.
Und da HFS+ am Mac die eindeutig bessere Wahl ist und es bei Linux am Ende keinen Unterschied macht, bedeutet das wohl, dass HFS+ das Dateisystem der Wahl für diese Aufgabe ist.

genau, das ist die anforderung. allerdings fehlt mir leider erfahrung bzgl. hfs+ auf Linux. aus dem gefühl heraus, scheint die implementierung noch eher experimentell zu sein. da es um datenbackups geht, würde ich doch sehr gerne etwas aus der kategorie "rock solid" einsetzen. im moment tendiere ich daher in richtung dedizierter server + samba.
 
catvarlog schrieb:
im moment tendiere ich daher in richtung dedizierter server + samba.
Da kannst Du Dir wenigstens sicher sein, dass Du die Daten nicht genau so zurückbekommst, wie Du sie hingeschickt hast;)
Von der Lösung kann ich für Datenbackup nur abraten.
Merke: Mac-Datenbackups niemals auf ein flaches Dateisystem. Es sei denn, Du legst ein Image mit Mac-Dateisystem an, welches Du auf dem flachen Dateisystem speicherst.

Wenn es ein dedizierter Server sein soll, könntest Du Dir allerdings Gedanken um Darwin/x86 machen. Das hat nämlich native AppleShare-over-IP- und HFS+-Unterstützung.
 
._ut schrieb:
Wenn es ein dedizierter Server sein soll, könntest Du Dir allerdings Gedanken um Darwin/x86 machen. Das hat nämlich native AppleShare-over-IP- und HFS+-Unterstützung.

Hast du da Links/Doku/HowTos?

Ich würde gern einen Fileserver für Macs (alle OS X) aufbauen, der auf Darwin basiert, da mir OS X Server nicht sonderlich gefällt. Die Doku scheint da aber extrem dünn zu sein (wen wundert's), ich habe es nicht mal ansatzweise gebacken bekommen...

Gruß,
Ratti
 
Nee, habe ich nicht.

Aber. Das System ist soweit selbstkonfigurierend, wie Mac OS X.
Bis auf die Netzwerk-Einstellung, da gibt es in HowTo für opendarwin.org/en/articles/network_config/ar01s02.html.
Die Tools sind die gleichen, wie Linux oder BSD.
 
._ut schrieb:
Da kannst Du Dir wenigstens sicher sein, dass Du die Daten nicht genau so zurückbekommst, wie Du sie hingeschickt hast;)
Von der Lösung kann ich für Datenbackup nur abraten.
Merke: Mac-Datenbackups niemals auf ein flaches Dateisystem. Es sei denn, Du legst ein Image mit Mac-Dateisystem an, welches Du auf dem flachen Dateisystem speicherst.

d.h.: wenn ich per rsync (rsync -e shh - also per ssh) daten des OS-X-Rechners auf die Linux Kiste sichere, zerschieße ich mir die Mac-Daten? Jetzt echt?! Gilt das auch für z.B. DocumentRoots eines OS-X Apache-Server? oder beziehst du dich gerade auf samba?
 
Zuletzt bearbeitet:
@ catvarlog
Doch, echt. Per ssh sowieso.
Wie ich schon weiter oben sagt hat das Mac Dateisystem besondere Fähigkeiten, die der Mac auch nutzt. Flache Dateisysteme und Netzwerk-Dateisysteme aber nicht.

P.S. Ich bezog mich in erster Linie auf die Aussage "ein gecraschtes OS-X system ggf. restaurieren" (was mit Daten, die auf einem flachen Dateisystem gespeichert wurden niemals klappen wird, aber auch kaum nötig sein wird).
Bei den Apache Daten dürfte das kein großes Problem sein.
 
Zuletzt bearbeitet von einem Moderator:
Ratti: Ne, werd's aber mal probieren, sobald ich ADSL hab ;)
 
Zuletzt bearbeitet:
._ut schrieb:
Bei den Apache Daten dürfte das kein großes Problem sein.

okay...! d.h. daten wie z.B. die documentroots des apachen, ein dump vom mysql als tgz und dateien von openoffice können per rsync/ssh gut gesichert werden. problematisch wird es dann - platt gesagt und wenn ich dich richtig verstanden habe - bei daten, die in irgendeiner form von OS X "selber" verwaltet werden oder aber auch bei anwendungsdaten, die die features des OS-X FS benutzen... wa?

gnu/darwin erscheint mir als interessante alternative, da es wohl unter der GPL steht, auf x86 läuft und hfs+ unterstützt. das würde mein hardware-problem lösen. (sprich: ich könnte im notfall einen beliebige x86-Rechner oder PowerPC lizenzkostenfrei aufsetzen und die die Backup-Festplatten mounten).

sehe ich das richtig, dass ich beim einsatz von gnu/darwin keine problem mit der rsync/ssh-Sicherung von Linux-Clients zu erwarten habe?


danke für deine und eure geduld :)
 
Zuletzt bearbeitet:
Zurück
Oben Unten