Reiser schneller als xfs auf Suse 10.2

Da ich meine Partitionen mit LUKS verschlüsseln will, ahbe ich die Gelegenheit genutzt einen Geschwindigkeitstest von den fs zu machen, um eventuell zu wechseln. Im Einsatz sind zwei Festplatten (SATA und PATA). Hier die überraschenden Ergebnisse die nicht per Bonnie & Co. ermittelt wurden sondern per einfaches kopieren mit time cp usw.

zuerst 7GB (eine Kopie des home-Verzeichnisses):

Reiser (PATA) > Reiser (SATA) : 249 sec
XFS (PATA) > XFS (SATA): 342 sec

kopieren von 6,9 GB (dvd-rip-Verzeichnis,aber mit sehr über 12.000 Dateien (Untertitel in Minidateien) und VOBS):

Reiser (PATA) > Reiser (SATA) : 255 sec
XFS (PATA) > XFS (SATA): 275 sec

dann 4,7 GB(1 Verzeichnis mit 5 großen Dateien):

Reiser (SATA) > Reiser (PATA) : 159 sec
Reiser (SATA) > XFS (PATA): 209 sec
Reiser (SATA) > JFS (PATA): 208 sec
Reiser scheint hier davon zu profitieren, das Quelle ud Ziel beide in Reiser sind. Analog sollte das auch für XFS und JFS zutreffen.

als letztes noch kopieren der 5 Dateien mit den 4,7 GB auf derselben Partition in ein anderes Verzeichnis:

Reiser (PATA) > Reiser (PATA) : 258 sec
XFS (PATA) > XFS (PATA): 303 sec
JFS (PATA) > JFS (PATA): 310 sec

Das Ergebnis ist eindeutig: Reiser ist auf meinem Rechner überraschend schneller als XFS zwischen satten 15-25%. Dabei lese ich doch überall was anderes. Selbst in der Paradedisziplin von XFS (große Dateien) ist Reiser schneller, nur nicht ganz so arg.

http://www.linux-user.de/ausgabe/2006/01/046-dateisysteme/index.html
http://www.linux-magazin.de/heft_abo/ausgaben/2004/03/pisa_studie/(kategorie)/349
ct 2002

Ist Reiser, weil es jahrelang das Standard-FS war, bei Suse besser integriert/umgesetzt als XFS und Co.?
Welche Erfahrungen habt ihr?

newbie1976 schrieb:

überraschenden Ergebnisse die nicht per Bonnie & Co. ermittelt wurden sondern per einfaches kopieren mit time cp usw.
zuerst 7GB (eine Kopie des home-Verzeichnisses):
Reiser (PATA) > Reiser (SATA) : 249 sec
XFS (PATA) > XFS (SATA): 342 sec

Zum Vergrößern anklicken....

(1) Bei XFS sind ab Kernel 2.6.17 standardmäßig Write Barriers zur Sicherheit an, wenn du also ein Test mit vielen Dateien machst, solltest du die vorher deaktivieren (mount -o nobarrier), um fair zu bleiben
(2) Wenn reiser3 und XFS-Partition zur gleichen Zeit existieren, dann muss eine davon logischerweise hinten liegen - da wo Datentransfers von der Platte langsamer sind.

Das Ergebnis ist eindeutig: Reiser ist auf meinem Rechner überraschend schneller als XFS zwischen satten 15-25%. Dabei lese ich doch überall was anderes. Selbst in der Paradedisziplin von XFS (große Dateien) ist Reiser schneller, nur nicht ganz so arg.

Zum Vergrößern anklicken....

Warte einfach ab, bis du mehr als einen CPU-Kern hast.
Außerdem müsstest du die Tests mehrmals durchführen um einen Durchschnitt zu erhalten, plus natürlich am besten immer, dass die Zielpartition im gleichen Zustand ist.

(1) Bei XFS sind ab Kernel 2.6.17 standardmäßig Write Barriers zur Sicherheit an, wenn du also ein Test mit vielen Dateien machst, solltest du die vorher deaktivieren (mount -o nobarrier), um fair zu bleiben.

Zum Vergrößern anklicken....

Von der neuen OPtion habe ich noch nix gehört gehabt. Dann werd ich den Test nochmal wiederholen.

(2) Wenn reiser3 und XFS-Partition zur gleichen Zeit existieren, dann muss eine davon logischerweise hinten liegen - da wo Datentransfers von der Platte langsamer sind.

Zum Vergrößern anklicken....

Nö, die existieren nicht gleichzeitig. Auf beiden Platten habe ich jeweils nur eine freie Partition. Beide wurden jeweils mit dem gleichen FS formatiert. Dann habe ich das zu kopierende Verzeichnis auf eine den beiden Partitionen/Platte kopiert (immer dieselbe) und noch einen Neustart durchgeführt (um den Cache 100% leer zu bekommen). Dann konnte der Kopiertest beginnen (SATA>PATA). Neustart und zweiter Durchlauf folgte. Die maximale Differenz zwischen diesen zwei Durchläufen betrug 2 Sekunden.
Für das nächste FS habe ich die selben Partitionen wieder formatiert usw. ....

Warte einfach ab, bis du mehr als einen CPU-Kern hast.

Zum Vergrößern anklicken....

Wieso sollte sich das auswirken? Mein Athlon64 3200+ (1Kern) läuft während den Tests bei 1 Ghz statt 2. Währe ja auch schlimm wenn das FS die CPU so auslasten würde ...

newbie1976 schrieb:

Das Ergebnis ist eindeutig: Reiser ist auf meinem Rechner überraschend schneller als XFS zwischen satten 15-25%. Dabei lese ich doch überall was anderes. Selbst in der Paradedisziplin von XFS (große Dateien) ist Reiser schneller, nur nicht ganz so arg.

Zum Vergrößern anklicken....

Ich frage mich gerade, warum in letzter Zeit XFS so viel Schlagzeilen macht und immer wieder so gelobt wird. Was bei diesen Geschwindigkeitstests immer wieder unterschlagen wird: der Platzbedarf. Man nehme viele kleine Dateien, z.B. portage-tree und vergleiche deren Grösse auf XFS und auf reiserfs oder reiser4. Dann sollte man noch nicht nur den CPU Bedarf, sondern auch den RAM-Bedarf eines FS mitbedenken und schliesslich die Sicherheit des FS...

Schade ist, dass in der Hinsicht so viel "Rad neu erfunden" wird und nicht weniger Zerstreuung stattfindet. Viele Dateisysteme die alle ihre Macken haben helfen leider keinem...

der neue Test mit -nobarrier bei xfs brachte dann das zu erwartende Bild:

zuerst 7GB (eine Kopie des home-Verzeichnisses):

Reiser (PATA) > Reiser (SATA) : 249 sec
XFS (PATA) > XFS (SATA): 254 sec

als letztes noch kopieren der 5 Dateien mit den 4,7 GB auf derselben Partition in ein anderes Verzeichnis:

Reiser (PATA) > Reiser (PATA) : 258 sec
XFS (PATA) > XFS (PATA): 245 sec
JFS (PATA) > JFS (PATA): 310 sec

Die neue Standard-Option, die die Datensicherheit erhöht, kostet ordentlich Performance (25-35%). Reiser bietet die Option soviel ich weiß nicht.

Was bei diesen Geschwindigkeitstests immer wieder unterschlagen wird: der Platzbedarf. Man nehme viele kleine Dateien, z.B. portage-tree und vergleiche deren Grösse auf XFS und auf reiserfs oder reiser4.

Zum Vergrößern anklicken....

Beide FS (auch Ext3) speichern in 4KB Blöcken. Wenn jetzt eine Datei 3KB groß ist, bleiben bei Ext3 und XFS 1KB frei/ungenutzt. Reiser nutzt die 1KB für die nächste Datei - "verschwendet" also keinen Platz. Kann man übrigens auch mit der Option notail abschalten und bringt ein bisschen Performance. Fragt sich nur, ob das bei den heutigen großen Festplatten Sinn macht. Ich habe zusammen 160GB und jede Menge freien Platz. Ob nun 7 oder 8 Gb ist doch da egal oder?

und schliesslich die Sicherheit des FS...

Zum Vergrößern anklicken....

Das wär meine nächste Frage. Wie sieht es da aus? Wie verhalten die sich, wenn mal der Strom weg bleibt und das FS inkonsistent wurde? Kann das FS dann auch ohne größten Datenverlust wieder in einen konsistenten Zustand gebracht werden? Hat da jemand "praktische" Erfahrungen "sammeln dürfen"?

tomte schrieb:

Was bei diesen Geschwindigkeitstests immer wieder unterschlagen wird: der Platzbedarf.

Zum Vergrößern anklicken....

Ich habe einige produktive Systeme von reiserfs auf XFS umgestellt und in keinem Fall einen erhöhten Platzbedarf festgestellt.
Akademisch gesehen werden viele kleine Dateien unter reiserfs platzsparender verwaltet, in der Praxis ist das IMHO nicht signifikant.

tomte schrieb:

Dann sollte man noch nicht nur den CPU Bedarf, sondern auch den RAM-Bedarf eines FS mitbedenken und schliesslich die Sicherheit des FS...

Zum Vergrößern anklicken....

Bzgl. RAM schenken sich die FS IMO nichts.
Bzgl. Sicherheit möchte ich daran erinnern dass XFS schon wesentlich länger als reiserfs existiert.
Und unter reiserfs gab es schon mehrere Situationen bei denen ich ein --rebuidtree durchführen musste (Dauer bei 150GB: ~2h).

tomte schrieb:

Schade ist, dass in der Hinsicht so viel "Rad neu erfunden" wird und nicht weniger Zerstreuung stattfindet. Viele Dateisysteme die alle ihre Macken haben helfen leider keinem...

Zum Vergrößern anklicken....

Das ist grundsätzlich richtig, aber XFS ist (wie erwähnt) nicht der Versuch ein neues FS zu etablieren sondern eine Portierung eines erprobten FS auf Linux.
Macken sehe ich eher bei reiserfs, die absehbar nicht beseitigt werden.

newbie1976 schrieb:

Warte einfach ab, bis du mehr als einen CPU-Kern hast.

Zum Vergrößern anklicken....

Wieso sollte sich das auswirken? Mein Athlon64 3200+ (1Kern) läuft während den Tests bei 1 Ghz statt 2. Währe ja auch schlimm wenn das FS die CPU

Zum Vergrößern anklicken....

Weil das Filesystem (insb. der reiser3-Journal) an eins, zwei Stellen den BKL verwendet. Ich kann dich zwar nicht auf die Corporate Server lassen, aber ich sag dir, dass `tar -xf linux-2.6.20.tar.bz2` das 8-Kern-System in die Knie zieht.

tomte schrieb:

Was bei diesen Geschwindigkeitstests immer wieder unterschlagen wird: der Platzbedarf. Man nehme viele kleine Dateien, z.B. portage-tree und vergleiche deren Grösse auf XFS und auf reiserfs oder reiser4. Dann sollte man noch nicht nur den CPU Bedarf, sondern auch den RAM-Bedarf eines FS mitbedenken und schliesslich die Sicherheit des FS...

Zum Vergrößern anklicken....

Vor 2.6.15/2.6.16 (weiß ich nicht genau, aber ist schon 'ne Weile her, Januar 2006) musste man für 2 TB reiser3 128 MB unswappbaren RAM und 3 Minuten Mountzeit einplanen, weil der Bitmap nicht gespeichert, sondern immer errechnet wurde. Da haben alle anderen Filesysteme besser abgeschnitten. Siehe http://kerneltrap.org/node/6089

tomte schrieb:

Was bei diesen Geschwindigkeitstests immer wieder unterschlagen wird: der Platzbedarf. Man nehme viele kleine Dateien, z.B. portage-tree und vergleiche deren Grösse auf XFS und auf reiserfs oder reiser4.

Zum Vergrößern anklicken....

Während reiser noch versucht, Dateien in einen Block zu quetschen, werde sie bei nicht-reiser schön offen hingelegt, damit man auch wieder schnell auf diese zugreifen kann.

newbie1976 schrieb:

Das wär meine nächste Frage. Wie sieht es da aus? Wie verhalten die sich, wenn mal der Strom weg bleibt und das FS inkonsistent wurde?

Zum Vergrößern anklicken....

Für mich: nicht gerade anders. Seit ich XFS am Start habe, ist überall -o nobarrier mit dabei. Seither gab's verschiedene Poweroffs durch Überspannung, z.B. durch (1) Blitzeinschlag in der Nähe oder (2) besch* Stromnetz im Wohnhaus - was allerdings zuerst dadurch kaputt ging waren einige Sektoren der Festplatte statt das Filesystem.

Noch eine kleine Nachreichungzum Thema Geschwindigkeit. Ich habe mal das 4,7GB-Verzeichnis mit den 5 Dateien auch mal Windows kopieren lassen:

Reiser (SATA) > Reiser (PATA) : 159 sec
XFS (SATA) > XFS (PATA): 122 sec
NTFS (SATA) > NTFS(PATA): 153 sec

Wenn Win.. auch Linix bei der Bootzeit um Längen schlägt, bei dem FS gootseidank nicht.

Stecker ziehen tut weder der Hardware noch dem FS gut, von daher bleiben lassen. Wenn ich mich jetzt nicht irre, "journalen" sowohl xfs als auch reiserfs metadaten, von daher kein unterschied. Unterschied könnte dann noch beim verzögerten Schreiben existieren, aber wie gross der ist kann ich nicht sagen.

Wir haben vor kurzem mal den portage-tree auf ne festplatte mit 4GB gesteckt, mit reiserfs ging er 20mal drauf, mit xfs nur 7 mal. Das ist ein kleiner Unterschied. Zudem dauert ein entpacken des gepackten trees auf xfs auch deutlich länger.

In den nächsten Wochen muss ich bei mir einmal neuinstallieren (kaputte Festplatte sei Dank), aber zwischen xfs, reiserfs oder reiser4 kann ich mich definitv nicht entscheiden. Alle haben ihre Vor- und Nachteile. Was mich allerdings bei allen ein bisschen stört: es ist zu wenig ueber die ganzen Zusatzoptionen bekannt, mit denen man ein Feintuning erreichen kann.

Ich hab ja nicht absichtlich den Stecker gezogen.

Zeig' doch bitte mal dein Portage-Tree, das erstaunt mich doch schon, dass der Unterschied so groß ist.

Vor/Nachteile:
reiser4 fehlen derzeit noch Quotas und ACLs.
xfs ist das einzige mir bekannte FS mit atomaren Quotas ("wenn sie aktiviert sind, dann stimmen sie"*), bei den anderen die /aquota.{user,group} verwenden gibt es immer eine Zeitspanne, in der unbemerkt Dateien erstellt werden und die Quotas so gefälscht werden können.

Na dann liste ich doch mal... mkfs.xfs -i size=512, um Inodes 512 groß zu machen, sodass auch große ACLs reinpassen.


* Bugs ausgenommen

jengelh schrieb:

Zeig' doch bitte mal dein Portage-Tree, das erstaunt mich doch schon, dass der Unterschied so groß ist.

Zum Vergrößern anklicken....

ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo/snapshots
such dir einen aus...