ext3, XFS, Reiser

debian user german

Christian
Hallo Leute,

ich muss mein System neu aufsetzen. Bisher verwende ich ext3 und bin
damit auch ganz zufrieden. Trotzdem wollte ich mal nachfragen was eure
Erfahrungen bzgl. Journaling FS sind. Im Netz gibt es so ein paar
Meinungen die ext3 als langsam beurteilen, Reiser erst in der Version
4 als sehr gut. XFS gibt es schon sehr lange, es soll schnell sein und
auch robust. Der Linux Magazin Artikel zu diesem Thema ist schon 3
Jahre alt.

Der eine oder andere hier stand bestimmt auch schon vor dieser Frage.
Vielleicht koennt ihr bitte kurz eure Meinungen kundtun.

Danke

Christian
                                            
Markus
Hi Christian,


ich verwende nur noch XFS. Es ist robust, sicher und schnell. Allerdings kann 
ich zu den anderen nix sagen, da ich sie schon Ewigkeiten nicht mehr 
verwendet habe. XFS kann ich auf jeden Fall empfehlen.

Viele Grüße
Markus
                                            
Eduard
Moin Markus!
Markus Heller schrieb am Mittwoch, den 09. März 2005:


Meine Erfahrung mit verschiedenen Dateisystem auf dem Laptop (habe alle
drei mehrere Monate verwendet):

 - ext3: manchmal sehr schnell, manchmal etwas zäh aber ziemlich robust.
   Auch bei Abstürzen IIRC keine verfälschte Daten bekommen o.ae.
   Nachteil: verschwendet Platz
 - ReiserFS 3.6: war ganz okay, im Schnitt (subjektiv) nicht schneller
   als Ext3, aber nachdem das FS ziemlich voll wurde, ist die
   Geschwindigkeit der Dateizugriffe gesunken. Auf der sicheren Hardware
   lief es ohne Datenverluste.
   Vorteil: sparrt Platz
   Nachteil: s.o., auf meinem Desktop hat sich ein Test-ReiserFS
   innerhalb von wenigen Stunden zerlegt, als da ein fehlerhafter
   RAM-Riegel eingebaut wurde. Ext3 lief zur gleichen Zeit fröhlich
   weiter.
 - XFS: läuft jetzt ca. ein Jahr lang, macht fast alles mit. Subjektiv
   muss ich sagen, dass die Geschwindigkeit mit der Zeit abnimmt, d.h.
   z.Z. wird es träger und träger.
   Nachteil: verfälscht manchmal Daten, sehr ärgerlich

Beim nächsten Umstieg wird es JFS sein. Auf AIX läuft es immerhin ganz
gut, warum also nicht auf Linux testen.

Gruss,
Eduard.
                                            
Paul
Hi, was wird denn da verfälscht?
Da musst du schon was genauer werden (FUD).

Paul
                                            
Eduard
#include <hallo.h>



Hallo? Kaputte Dateiinhalte ohne Warnung sind ein KO-Kriterium.

Beschädigt war meistens eine der Dateien, die zuletzt geöffnet wurden.
IMHO auch längere Zeit nach dem letzten Zugriff auf diese Datei.

.bash_history, manchmal Pakete im Apt-Cache, manchmal Programme, die
daraus installiert wurden.

Diesen Sc****s habe ich schon einmal vor ca. zwei Jahren bemängelt,
damals ist sehr viel öfter etwas verfälscht worden. Vor ca. einem Jahr
wurde "Das Problem" angeblich gefunden und behoben, aber leider wohl
nicht ganz.

Und "genauer" geht es schlecht, das sind Langzeiteffekte in komplexen
Systemen und Troubleshooting ist zu aufwendig. Bugbeschreibung auch.

Eduard.
                                            
Paul
Mir ist schon klar, dass das ein K.O.-Kriterium ist.
Da ich aber noch keine dieser Fehler hatte, würde ich natürlich gerne
wissen, wie die zustande gekommen sind.

Wann sind den die Files defekt gewesen? nach einem Reboot, im Betrieb,
nach einem Absturz / Stromausfall, war es sicher kein User-Fehler, ...?

Die Beschreibung ist einfach unzureichend. Da brauchst du mich nicht
anzumeckern, sondern kannst das ganz neutral schreiben.

Paul
                                            
Kai
Ich kann die Erfahrungen von Eduard leider bestätigen. XFS verursachte
bei Abstürzen Datenmüll in Dateien. Dies waren Dateien, in die zuletzt
geschrieben wurde. Wenn ich mich recht erinnere, waren die Dateien dann
voller "\0".

Ich verwende nun ausschließlich ext3 auf allen Partitionen. Das
entscheidende Kriterium für mich war -- neben der spürbar besseren
Stabilität -- dass man ext3-Partitionen vergrößern _und_ verkleinern
kann.

Wenn jemand JFS ausprobiert oder benutzt würde mich interessieren, ob
die Unverträglichkeiten hinsichtlich UTF-8-Dateinamen verschwunden sind.

Kai
                                            
Ingo
Ich kann das nicht (in diesem Ausmass) bestaetigen. 


Das binary zero Problem ist eigentlich Geschichte. Muss man sich heutzutage
eigentlich keinen Kopf drum machen. 


Schoen. Dafuer zersemmelt ext3 mir in aller Regelmaessigkeit das FS beyond
repair. 
Was ist besser? Ein paar *eventuell* kaputte Dateien oder ein komplettes
Dateisystem in lost+found? Ext3 hat sich jedenfalls fuer *mich* als total
instabil erwiesen. XFS hingegen funktionierte auch unter widrigsten
Bedingungen zufriedenstellend. 

Kurzum: Die Frage nach dem richtigen Dateisystem muss jeder fuer sich selber
beantworten und ist genauso ueberfluessig wie die Frage nach dem richtigen
Editor.
                                            
Christian
Hallo Ingo,

danke fuer Deine Erfahrungen mit ext3 und XFS.
 
Ich habe lediglich um Meinungen und Erfahrungen gebeten. Das hast Du
ja auch getan, nochmal recht herzlichen Dank dafuer.
Ein Erfahrungsaustausch ist IMHO sehr wertvoll und vor allem
zeitsparend. Ich habe keine Zeit alle Dateisysteme zu testen um
schliesslich nach einigen Monaten und x Stunden Arbeit, die
Erfahrungen anderer zu bestaetigen. Das mag bei Dir anders sein.

Mit eurer Information kann ich nun die Frage nach dem richtigen
Dateisystem fuer mich beantworten. Danke an alle.

Gruss

Christian
                                            
Dirk
Und? Läßt Du uns im Gegenzug auch an Deiner Entscheidung und den
Beweggründen teilhaben?

ciao, Dirk
                                            
Ingo
Ich hatte das durchaus massiv frueher. Damals trat das aber auch bei einem
ordnungsgemaessen Shutdown auf, nicht "nur" bei einem Crash... 
Ich glaube, es sollte einleuchtend sein, dass bei einem Crash alles
moegliche mit einer Datei passieren kann und man ganz einfach nichts dagegen
machen kann. 


Das fsck ist bei XFS angenehm zuegig... :-) 
 

Ich benutze fast ausschliesslich XFS. Nur gewisse Archs mit gewissen 2.2er
Kernel sind noch ausserhalb von /boot mit ext2/3 unterwegs... 
 

Erwaehnte ich schon, dass ich Sun nicht mag? Muss wohl daran liegen, dass
ich aus der SGI-Ecke komme. Aber wenn OpenSolaris fuer die ODW/Pegasos
Rechner fertig ist, werde ich mir das auch mal anschauen... 
 

Ganz einfach: Der Bedarf ist nicht da. 
Die Entwickler auf #xfs haben sich mal dahingehend geaeussert, dass man das
Verkleinern durchaus auch implementieren koennte, wenn es ein (zahlender)
Kunde wuensche. Nur braucht es anscheinend niemand (ausser ein paar
LVM-Linux-Freaks), also werden die wenigen Ressourcen, die man hat, nicht
auf Features verschwendet, die eh niemand (Zahlendes) braucht. 
Und mal ehrlich gesagt: *ich* hab eigentlich noch kein FS gesehen, was immer
kleiner wurde. Vielmehr kenne ich nur FS, die nur eine Groessenveraenderung
kennen: nach oben!


In der Tat... wobei ich da nun auf einem Raid irgendwie auf einen seltsamen
Effekt gestossen bin, aber naja...
                                            
Ingo
Meine Abneigung gegen Sun ist ziemlich trivial: 
- ich finde deren Design im Vergleich zu dem der SGIs geradezu haesslich
- die Tastaturen sind einfach nur schauderhaft vom Layout her... 
Also vollkommen objektive Gruende... ;)


:-)


Tja, das verstehe ich ja z.B. auch nicht... 
Staendig wird herumgelaestert, dass XFS kein shrinking kann, aber niemand
kommt auf Idee, da mal selber seine Nase in den vorhandenen Source-Code zu
stecken und es dann halt mal zu implementieren, obwohl man ansonsten bei
jeder noch so kleinen Gelegenheit ein UTSL an den Kopf geschmissen
bekommt... ;)


Naja, wer solch eine Funktionalitaet braucht, kann ja auch zum CXFS greifen.
;)
Ich persoenlich kaeme z.B. nie auf die Idee, ein LVM ueber mehrere Platten
hinweg ohne (mindestens) ein RAID(5) zu benutzen... 
 

Naja, auf dem P200 dauert das so oder so schon was laenger... ;) 
Aber der Effekt war der, dass scheinbar alle Files eine recht hohe
Fragmentierung bzw. Anzahl der extents aufwiesen (ca. 67, 48 oder 27). 

Lustigerweise stelle ich allerdings gerade fest, dass das nicht die Files
auf dem Raid betrifft, sondern auf /.... *sehr* strange... ;)

Naja, mal weiterhin beobachten...
                                            
Kai
Falls man eine Partition zu groß bemessen hat und diesen Platz für eine
andere Partition nutzen möchte, ist Verkleinern schon praktisch, weil
das dann ganz ohne Umkopieren funktioniert.

Kai
                                            
Kai
Da ich endlich einen Namen für das Problem habe, habe ich gleich einmal
gesucht und einen sehr erhellenden Thread auf der XFS-Mailingliste
gefunden. Er beginnt hier:

http://marc.free.net.ph/message/20050211.121829.ad580ed2.en.html

Kurz: XFS garantiert nur Dateisystemkonsistenz. Die Datensicherheit
kann nur von Backups, RAID, UPS usw. kommen.


Da hast du natürlich recht. Dennoch fehlen einfach an manchen Stellen
die notwendigen Informationen, die zur Beantwortung der Frage notwendig
sind. Und nach denen darf man gerne hier Fragen, denke ich.

Kai
                                            
Ingo
Ja eben... Datei kaputt? Backup hernehmen und restoren... 
Allemal besser, ein paar vereinzelte Dateien restoren zu muessen, als nahezu
das komplette FS... ;)


Klar darf man. Nur ob man die gewuenschte Antwort erhaelt ist mehr als
fraglich, da jeder seine eigenen Erfahrungen gemacht hat. Ergo muss man
selber seine eigenen Erfahrungen sammeln. 
Meine Erfahrung besagt:
Es gibt kein absolut sicheres FS. Die Qualitaet eines FS macht sich vor
allem dann bemerkbar, *wenn* es zum GAU kommt. Und *jedes* FS wird frueher
oder spaeter einen solchen GAU haben. 
Wie man dann allerdings an seine Daten herankommt, ist sehr unterschiedlich.
Ext3 faellt zurueck auf ext2 und macht einen fsck.ext2/3 Run, was darin
enden kann, dass das FS verschlimmbessert wird und quasi das gesamte FS
hinueber ist.
Mit XFS hab ich selbst bei RAM-Fehler und badblocks auf der Platte noch
*sehr* gute Ergebnisse gehabt. Es waren Dateien kaputt, aber das FS war
eigentlich immer weitestgehend les- und benutzbar, eventuell erst nach einem
xfs_repair -L oder ein paar xfs_db Tricks, aber ich hatte nie einen
groesseren Datenverlust. Selbst nicht mit defekter Hardware ueber Monate
hinweg...

Momentan vertraue ich in dieser Hinsicht nur zwei Filesystemen meine Daten
an, da das worst case scenario bei beiden gute Ergebnisse bringt: XFS und
AmigaFFS. :-)
                                            
Roland
Kann man auch erkennen bzw. wird man informiert, welche Datei(en) defekt
ist/sind? Oder anders gefragt: Wie erfährt man, welche Datei(en) zurück
gesichert werden muss/müssen?
                                            
Kai
Zu möglichen Strategien für das Erkennen siehe die anderen Antworten.
Praktisch ist es so, dass man es erst bei Zugriff auf die Datei erkennt.

Aus irgendeinem Grund betraf das bei mir immer Dateien, die beim
Hochfahren benötigt werden, was dann regelmäßig auf Reparieren oder gar
komplett Neumachen mittels Rescue-CD hinauslief. Da wünschte ich mir
etwas einfacheres, das nur die betroffenen Dateien erkennt und
austauscht (womit sich der Kreis deiner Frage schließt und ich
vielleicht mal ein Projekt starte).

P.S. XFS hat gerade auf einer Partition eine 2. Chance bekommen.

Kai
                                            
Roland
Das äußert sich wie?
 

D.h. es war aufgrund von Fehlermeldungen oder Fehlfunktionen klar
erkennbar, dass irgendwelche Dateien defekt waren.


Wäre kein größeres Problem, sofern man den Defekt eindeutig erkennen
kann. Was aber, wenn z.B. eine in Ordnung ist, der Inhalt aber Schaden
genommen hat oder eine letzte Änderung nicht geschrieben wurde?


Hab bislang ext3 problemlos im Einsatz und wollte den neuen Server mit
XFS testen.
                                            
Kai
Genau so.


Soweit ich das verstanden habe, passiert das mit XFS nicht. Dann wäre
die Datei voller binary-zeros. Das passiert immer dann, wenn eine Datei
zum Schreiben geöffnet wurde, die Metadaten schon ins Journal
geschrieben wurden, die Daten jedoch noch nicht. Aus Sicherheitsgründen
füllt XFS die Datei dann mit "\0".

Im Falle eines Stromausfalles müsste man also alle vor dem Absturz
geöffneten Dateien nach Datenverlust überprüfen. Stellt man das nämlich
erst nach dem Backup-Zyklus fest, sind die Daten verloren.

Kai
                                            
Ingo
Ich wuesste nicht, wie man das generell erkennen sollte (also weder bei XFS
noch bei anderen FSen)?
Es sei denn, man vergleicht direkt mit einem vorhandenen und aktuellem
Backup und kopiert dann nur die Files zurueck, die das gleiche Datum,
Groesse, aber nicht den gleichen Inhalt haben...
                                            
Roland
Für statischen Dateien ist das sicherlich ein Lösung, was ist aber mit
veränderlichen Dateien wie z.B. von einer Datenbank. XFS stellt sicher,
dass das Filesystem in Ordnung ist, einzelne Dateien aber möglicherweise
fehlerhaft sind. Demnach würde ein fsck keine Fehler melden, die
Datenbank könnte aber beschädigt oder inkonstistent sein. Letzteres wäre
natrülich das größere Problem, weil man das ja nicht unbedingt sofort
erkennt.
                                            
Mario
Naja, heutzutage ist CPU an der Stelle eher nicht das Problem.
Bottleneck ist vielmehr das I/O-System. Und drum wirst Du wohl
kein performanteres Checksumming hinbekommen - selbst wenn es
weniger CPU braeuchte.


regards
   Mario
                                            
Mario
Naja, da md5sum nunmal das gesamte File lesen muss, ist es naturgemaess
zumindest wenig effizient :)
Es gibt Heuristiken, die das abkuerzen, diff kennt z.B.:
       --speed-large-files
              Assume large files and many scattered small changes.
Offensichtlich kommt damit eine gewisse Unsicherheit ins Spiel - wie
gross die ist haengt halt davon ab, wie gut die Heuristik auf die
Realitaet passt :)


regards
   Mario
                                            
Juergen
Ich habe schon mal rsync (das per Default auch sowas macht) dabei
erwischt, daß es die Subversion-DB nicht korrekt abgeglichen hat.
Alles außer dem Inhalt war gleich geblieben, inkl. Datum.

Da war übrigens kein Absturz passiert, nur normale Benutzung.


Jürgen
                                            
Michael
Man sollte aber auch erwähnen, das alle Journalled Filesystems in
erster Linie nur die Dateisystemkonsistenz sicherstellen sollen.

Michael
                                            
Helmut
[XFS]

D.h. mit Kernel 2.8.6 müste XFS problemlos laufen?


Na dann werde ich XFS mal ausprobieren. Mein apt-proxy müsste eh auf 
meinen DRBD-Cluster. Nachdem apt-proxy zeitweise absemmelt, und 
apt-proxy keine unwiederbringlichen Daten enthält, wär das ein gutes 
Testobjekt.

Helmut Wollmersdorfer
                                            
Ingo
Zumindest tat es das hier lange Zeit lang (auf etlichen Rechnern).


S. meine andere Mail: Die Qualitaet eines FS mache *ich* anhand des
Verhaltens im Falle eines Fehlers fest - und jedes FS hat/macht Fehler!
                                            
Paul
Auf einem Laptop oder einer Workstation wohl häufiger...
Na wenns wirklich am FS liegt... ist es schon fies.

Paul