|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
Von Anonymer Feigling am Thursday 22. August, 09:09 MES (#2)
|
|
|
|
|
Wuerde mich auch interessieren ... Bis jetzt bin ich "XFS"-er, da
- ext3: persoenlich schon negative Erfahrungen gemacht (kernel panics!)
- ReiserFS: hat nicht mal ein dump-Kommando
- JFS: war beim c't-Test das einzige, das Daten verloren hat
Bei Filesystemen ist mir bewaehrte Technik (XFS ist uralt) lieber als Neuentwicklungen (ext3, ReiserFS), schliesslich vertraue ich dem Ding meine Daten an. JFS wuerde eigentlich in die erste Kategorie gehoeren.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 22. August, 13:29 MES (#6)
|
|
|
|
|
|
Also mein Chef steht und setzt konsequent auf ReiserFS und sagt auch, er hätte noch nie Probleme damit gehabt, inbesondere im Gegensatz zu Ext2.
Die Zahl derer, die sich mit ReiserFS massiv ins Bein geschossen haben (jeder, der z.B. den von ReiserFS gerne erzeugten Dateimischmasch nach unsanftem Stromentzug gesehen hat, weiß wovon ich rede), ist allerdings groß. Seltsamerweise gibt es immer wieder einige Inseln, auf denen scheinbar nichts passiert.
Als mir aber letzthin wegen Temparaturproblemen (*args* ich brauche einen Festplattenkühler!) meine SCSI-Platte mit Fehlern nur so um sich geschmissen hat, scheinen doch einige Fehler ins Filesystem gekommen zu sein, die Ext3 weder korrigiert noch erkannt hat. Erst das regelmäßige Ext2-fsck hat sie gefunden und ich durfte sie dann manuell reparieren.
Gegen Schreibfehlern infolge von Hardwaredefekten hilft Journaling genau nichts.
-al
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 22. August, 14:48 MES (#7)
|
|
|
|
|
Eine richtige Antwort gibt es hier nicht, es kommt auf den Einsatzzweck und die persönlichen Vorlieben an.
Ich würde vor allem unterscheiden zwischen Meta-/Datenjournalling, Verwaltungsalgorithmus (B-Tree?), Performanz für kleine/grosse Skalen, Zusatzfeatures, Unterstützung durch existierende Tools, bereits im Standardkernel oder nicht.
Letzteres ist sehr wichtig, wie man bei XFS erfahren konnte. Der Linux-Kernel ist ein derartiges Gewurstel, dass kleine Änderungen am Code oft negative Auswirkungen an ganz anderen Orten haben. Solange der FS-Code nicht im Kernel ist, fallen Nebenwirkungen von Änderungen im Kernel erst auf, wenn es schon zu spät ist (Datenverlust schon eingetreten, Kernel bereits veröffentlicht).
Auf IBM DeveloperWorks hat es 11 gute Artikel dazu:
http://www-106.ibm.com/developerworks/opensource/library/l-fs11.html?dwzone=opensource
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Linux-Kernel ist ein derartiges Gewurstel, dass kleine Änderungen am Code oft negative Auswirkungen an ganz anderen Orten haben.
Kannst Du das ein wenig ausdeutschen für z.B. einen C-unkundigen wie mich, der zwar schon einige Kernel konfiguriert und kompiliert, sich aber noch nie in die Lektüre der Kernelsourcen vertieft hat? Danke!
|
|
|
|
|
|
