Mario van der Linde wrote:

[...] Ich setze jfs ein und bin relativ zufrieden. Relativ weil jfs nicht so performant ist wie xfs z.B. Aus eigener Erfahrung kann ich meine bisher (produktiv) eingesetzten Dateisysteme wie folgt platzieren: 1. Platz: XFS - superschnell bei vielen kleinen Dateien, lief bei mir immer stabil (habe ich aber wg. der Inkompatibilität der 9.1 abgeschafft - leider ...) 2. Platz: JFS - langsamer als XFS, aber genauso stabil 3. Platz: ReiserFS - schneller als JFS, lief bei mir aber sehr unstabil. Nach dem 5. --rebuild-tree hab ich es von der Platte geschmissen...

ext2 setze ich für /boot ein, wegen dem fehlendem Journal fällt das wohl aber aus der engeren Wahl raus.

Fuer grosse Partitionen sicher. Aber es waere IMHO trotzdem mal interessant, es mit den anderen FS zu vergleichen. Und wenn Stonki schon momentan die Moeglichkeit dazu hat, warum nicht :-) Ich denke, auf kleinen Partitionen oder Speichermedien wie USB-Sticks o.ae. macht ext2 weiterhin Sinn, da braucht man kein Journal. Eigentlich muesste es sich ja aehnlich verhalten wie ext3, ist doch ext3 ein um ein Journal erweitertes ext2.

Mit ext3 hab ich mal ein wenig herumgespielt, habs aber nicht produktiv eingesetzt. Deswegen kann ich das auch nicht wirklich bewerten. Aber sehr fix scheint das auch nicht zu sein...

Das liegt in der Natur der Dinge, da ja hier lineare Listen zum Adressieren verwendet werden und keine Baeume. Bei mir ist ext3 auch z.B. beim Loeschen grosser/vieler Dateien schon deutlich langsamer als z.B. xfs, aber es ist halt auch immer die Frage, wie wichtig einem solche Feature sind und ob es sich in der Praxis (sprich: im Alltag) wirklich deutlich negativ bemerkbar macht. Wir haben hier eine Mischung aus ext3 und xfs im Einsatz, was sich bisher als sehr gut herausgestellt hat. Von ReiserFS haben wir aufgrund unserer eigenen Erfahrungen auch Abstand genommen. CU, Th.

Stefan Onken wrote:

da mein SuSE 9.1 gestern anfing rumzuspinnen, habe ich (wollte ich eh) auf Gentoo umgestellt und alle Tests - diesmal inkl. "jfs/ext2" noch einmal gemacht... Sehr interessant - vor allem zum Vergleich mit den SuSE 9.1 Werten, ich bin ein wenig ueberrascht wie schnell doch unsere SuSE ist....

Was noch interessant gewesen waere: ich nehme an, der Test unter SuSE 9.1 lief mit dem dortigen Kernel bzw. mit einem SuSE-Kernel. Was waere wohl herausgekommen, wenn man die gleichen Tests unter SuSE 9.1 nun mit einem Vanilla-Kernel gemacht haette...? Ach, ein nettes Spielzeug hast Du da gerade :-) CU, Th.

Stefan Onken schrieb am 08/08/2004 10:52 AM:

da mein SuSE 9.1 gestern anfing rumzuspinnen, habe ich (wollte ich eh) auf Gentoo umgestellt und alle Tests - diesmal inkl. "jfs/ext2" noch einmal gemacht... Sehr interessant - vor allem zum Vergleich mit den SuSE 9.1 Werten, ich bin ein wenig ueberrascht wie schnell doch unsere SuSE ist....

http://www.stonki.de/Filesysteme.96.0.html

Mich würde ja interessieren, ob's mit den gentoo-dev-sources anstatt der development-sources bessere Ergebnisse gibt... Michael.

Stefan Onken schrieb am 08/08/2004 11:59 AM:

Am Sonntag, 8. August 2004 11:51 schrieb Michael Schachtebeck:

...

Mich würde ja interessieren, ob's mit den gentoo-dev-sources anstatt der development-sources bessere Ergebnisse gibt...

das werde ich (zumindest fuer ein Dateisystem) mir auch noch anschauen. Wie kann ich am besten wechseln ?

Nichts einfacher als das: emerge gentoo-dev-sources cd /usr/src/linux-2.6.7-gentoo-r12/ (zur Zeit aktuelle Version) make menuconfig [jetzt Kernel konfigurieren] make evtl. noch make modules_install Dann noch System.map und arch/i386/boot/bzImage nach /boot kopieren und den Bootloader anpassen, fertig. Ausführlicher: http://www.gentoo.org/doc/de/handbook/handbook-x86.xml?part=1&chap=7 für den Kernel http://www.gentoo.org/doc/de/handbook/handbook-x86.xml?part=1&chap=9 für den Bootloader Michael.

Stefan Onken schrieb:

[...] Hardware liegen. Wenn Du also noch einen Test im Hinterkopf hast was Du schon immer mal testen wolltest, aber nie eine Partition ueber hattest, dann ist NUN der richtige Zeitpunkt..

Für den Einsatz auf Workstations könnte folgender Test interessant sein: Ein paar GB Dateien vorgegebener Größe mit darin enthaltener Prüfsumme schreiben. Gleich danach einen harten Reset ausführen. Nach dem Neustart prüfen welche der geschriebenen Dateien da sind und ob die Prüfsummen stimmen. Angeblich soll Reiserfs bei diesem Szenario besser sein als XFS. Aus diesem Grund setze ich meine privaten Kisten seit neuestem mit Reserfs statt XFS auf. -- Gruß, Alex

Da die Standard bdflush Parameter 30 Sekunden Schreibverzögerung zulassen ist das kaum ein Test für das Dateisystem oder?

Wenn das Caching nicht vom Dateisystem abhängig ist, nicht.

Eher wie lange den das Reparieren beim Neustart dauert.

Das auf jeden Fall :-)

Stefan Onken wrote:

Am Samstag, 7. August 2004 23:26 schrieb Alexander Veit:

...

Ein paar GB Dateien vorgegebener Größe mit darin enthaltener Prüfsumme schreiben. Gleich danach einen harten Reset ausführen.

Nach dem Neustart prüfen welche der geschriebenen Dateien da sind und ob die Prüfsummen stimmen.

sag mir mal, wie ich am besten die Pruefsummen bilde. Ich habe ca. 10 GB an Daten mal raufgeschoben nur wenn ich jetzt mit "md5sum" die Pruefsumme fuer JEDES File bilde, dann haben wir Listen ueber Listen. Irgendeinen praktikablen Vorschlag ?

Hilft evtl. ein <ungeprueft> find \irgendeinverzeichnis -type f -exec md5sum {} \; > pruefsummenvorher.txt --> neustarten find \irgendeinverzeichnis -type f -exec md5sum {} \; > pruefsummennachher.txt diff pruefsummenvorher.txt pruefsummennachher.txt </ungeprueft> Joachim

Am Samstag, 7. August 2004 16:58 schrieb Christian Boltz:

Ich persönlich setze nur ext3 ein (nachdem man bei Reiserfs doch ab und zu von Problemen liest).

Und dieser Bug ist doch irritierend: Confirmed BUG in reiserfs with SuSE kernel 2.6.5* (name clash) http://lists.suse.com/archive/suse-security/2004-Aug/0030.html Al

Am Samstag, 7. August 2004 20:26 schrieb David Haller:

Goil. Kannst du da nochmal nen Lauf drueber jagen, wo die fehlenden Werte mit dabei sind (also "Sequential Create" -> "Delete" bei Ext3)? Dass die "* Create" -> "Read" Werte fehlen liegt wohl an bonnie++ oder?

ganz ehrlich: ich weiss nicht wieso die fehlen. zu den anderen Punken: ich hatte irgendwie Kernels Probs (Kernel Ops mit irgendwas wie Atomic time). Ich habe mir nun (wollte ich eh) Gentoo installiert, ich teste nachher weiter. (dann kann man gleich mal sehen, ob unterschiedliche Distris sich anders verhalten). cu stonki -- www.stonki.de: the more I see, the more I know....... www.proftpd.de: Deutsche ProFTPD Dokumentation www.krename.net: Der Batch Renamer für KDE www.kbarcode.net: Die Barcode Solution für KDE

Hallo, Am Sun, 08 Aug 2004, Stefan Onken schrieb:

Am Samstag, 7. August 2004 20:26 schrieb David Haller:

...

Oder auch diverse Kopier- oder Verschiebeaktionen (passender Datenmengen). Z.B. mit tar (vgl. maddin_kopieren.html der SDB).

total interessant ! XFS ist schneller als ReiserFS bei diesem Test.

*hihi* tar sollte dabei uebrigens nicht allzuviel CPU schlucken, so eine Kopieraktion misst also ziemlich die HDD und FS Leistung ;) BTW: IMHO machst du beim Erstellen der Datei einen Fehler, denn bei time dd if=/dev/urandom of=testfile bs=1024k count=500 misst du wohl eher deine CPU (urandom generiert die Zeichen IIRC mehr oder weniger per MD5, sobald der "echte" Zufallszahlen Puffer (meist 512 Byte) aufgebraucht ist. Und anhand der fast identischen Werte wage ich zu behaupten, dass dies bei dir hier der Fall war. Besser evtl. du generierst die Datei ohne 'time' vorher und legst dann die eigentliche Datei durch kopieren / cat an, idealerweise zu einem grossen Teil aus dem FS-Cache: cat /datei > /dev/null # caching ausnuetzen cat /datei > /mnt/ext2/datei cat /datei > /mnt/ext3/datei cat /datei > /mnt/reiserfs/datei cat /datei > /mnt/xfs/datei cat /datei > /mnt/jfs/datei (oder so aehnlich, wobei ich die Reihenfolge u.U. auch mal iterieren wuerde um zu schauen ob das relevant ist). -dnh --

aalib? libcaca? -- J. Walzer Wer kommt auf die Idee, seine Libraries nach menschlichen Exkrementen (und dazu noch in zwei verschiedenen Sprachen) zu bennenen? -- C. Eineke

Joerg Rossdeutscher wrote:

Mal 'ne ganz ketzerische Frage:

Ich haette gerne zwei spitze und zwei flache Steine und ein Paket Kies... :-) (*)

Während der gemeine Linuxuser sich mit seinesgleichen die Köppe einhaut, ob denn nun reiserfs oder ext3 geekiger und cooler sei, höre ich bei Unterhaltungen zwischen den erwachsenen Jungs immer nur "xfs" und "jfs" - und daß diese beiden schneller, stabiler, sicherer, professioneller, ... wären. Wenn ich das aus dem Munde von Leute höre, deren Rat meist Gold wert ist und deren Tips man am besten erstmal glaubt, dann drängt sich mir eine Frage auf:

Wieso kommen eigentlich die meisten Distris defaultmässig mit reiserfs/ext3 raus, wenn es so offensichtlich besseres gibt?

Naja, so offensichtlich ist das ja nicht. Alle Filesysteme (FS) haben ihre Staerken und ihre Schwaechen, alle Distributoren haben ihre jeweiligen Favoriten, und die Anwender haben dann auch noch eine gewisse Meinung... Alles mehr oder weniger fundiert. Von der Theorie her ist ja ReiserFS eine sehr gute Sache und sicherlich als Default-FS fuer eine Distribution eine gute Wahl - wenn da nur nicht immer wieder die seltsamen Erlebnisse waeren, von denen man hoert und denen ich selbst z.B. auch schon zum Opfer gefallen bin. Das macht misstrauisch. Wenn dem nicht so waere, wuerden vermutlich auch mancher meiner Rechner dieses FS benutzen. Warum ext3 so verbreitet ist, sollte relativ offensichtlich sein - es basiert auf dem sehr stabilen ext2 FS und, fast noch besser, eine bestehende ext2 Partition laesst sich ohne Probleme in ext3 umwandeln (wobei Rueckwaertskompatibilitaet erhalten bleibt). >

Fragt: Ratti, dere seit einigen Wochen auch eine xfs-Partition hat, sie noch ein klein wenig xenophob beäugt, aber eigentlich ganz zufrieden ist...

Allerdings hat das ext3 FS aufgrund seiner Abstammung natuerlich

auch in etwa die Nachteile von ext2 geerbt (z.B. lineare Adressierung). Ext3 und ReiserFS sind sicherlich die FS, die auf einem Standard-PC am ehsten zum Einsatz kommen. ReiserFS als besser optimiertes FS prinzipiell mit einigen Vorteilen, gerade was Geschwindigkeit bei vielen Dateien etc. angeht. XFS und JFS kommen ja nicht direkt aus dem Linux-Sektor sondern sind Portierungen, die es noch nicht all zu lange gibt. Alleine das macht sie vermutlich schon einmal etwas weniger bekannt unter z.B. den "typischen" SuSE-Anwendern. Unter den "erwachsenen Jungs", wie Du es nennst, kennt man diese FS schon eher. Diese FS wurden ja fuer Grossrechner designed (wenn man bedenkt, wann XFS entstand, schon eine bemerkenswerte Voraussicht von SGI bei der Implemetierung). Mit JFS habe ich selbst keine Erfahrung, aber XFS hat hier definitiv bei grossen Partitionen und grossen Dateien durchaus Vorteile. Es ist auch schon sehr lange das Standard-FS auf unseren SGI Maschinen - dort ist es "rock solid" und hat sich bewaehrt, weswegen natuerlich hier auch der Einsatz unter Linux zum Tragen kam. Neben den objektiven Gruenden, die fuer oder gegen das ein oder andere FS sprechen, spielen auch sehr viel der eigene Geschmack und die eigenen Erfahrungen eine Rolle. Da geht es also dann doch sehr subjektiv zu. Wenn man mit einem FS gute Erfahrungen gesammelt hat, ist man dann doch dazu geneigt, bei diesem FS zu bleiben. Du selbst hast ja auch gesagt, dass Du das bei Dir neue XFS doch ein wenig befremdlich beaeugst. In Zukunft kommt dann noch Reiser4 hinzu (nein, das ist nicht einfach eine Weiterentwicklung von ReiserFS), und dann wird auch wieder die Diskussion losgehen. Ich sehe das alles nicht so wild. Es ist ja schoen, dass es die grosse Auswahl gibt. Und solange man mit "seinem" FS zufrieden ist und keine Probleme hat, ist das doch gut. Gruesse, Th. (*) Life of Brian, Monty Python