Hi, Am Sonntag, 3. November 2002 22:11 schrieb Thomas Hertweck:

advreg wrote: ^^^^^^ Es waere schoen, wenn auch Du Deinen Realnamen beim Schreiben benutzen koenntest.

das habe ich leider zu spät bemerkt. Da ich alles ja neu einrichten musste, ist mir das durchgerutscht. Hier also der Realname :-)

...

[...] Ach so noch eine Abschlussfrage: Ext2, EXt3 sind mir von der Struktur her zu veraltet, deshalb benutze ich ja immer noch Reiser. Kann jemand schon ernsthaft JFS und XFS empfehlen? Tschuldigung: Ich weiß ja, dass das eigentlich schon wieder ein anderer Thread ist :-)

Was verstehst Du unter "veraltet"? Nur weil es ext2 schon lange gibt muss es ja nicht schlecht sein. In manchen Dingen bietet ReiserFS sicher Vorteile gegenueber ext2/ext3, aber ich habe damit leider schon sehr unangenehme Ueberraschungen erlebt.

Du also auch !!!

Mit ext3, was bei uns standardmaessig auf Linux-Maschinen eingesetzt wird, sind wir eigentlich sehr zufrieden.

Tja, über Ext3 habe ich auch schon nachgedacht wegen des Journaling einerseits und seiner Bewährtheit andererseits und so ein Riesenanwender bin ich ja nun auch wieder nicht, sondern "nur" ein single user. Andererseits benutze ich ja nun gerade deswegen Reiser, weil das bezüglich vieler kleiner Dateien immer wieder über den grünen Klee gelobt wird.

Auf einigen Datenplatten setzen wir hier seit einer Weile auch xfs ein, weil wir es selbst mal testen wollten. Bisher gab es ueberhaupt keine Probleme damit. Das Filesystem bietet AFAIK bei grossen Dateien gewisse Performancevorteile. Aber bei den ganzen Journaling-Filesystemen streitet man sich ja eh, welches nun die erste Wahl ist :-)

Also am meisten würde mich dann tatsächlich XFS reizen. Vom theoretischen Ansatz her fand ich das ja schon seit längerem am besten. Würde es gerne mal einsetzen, wenn ich die SuSE8.1 auf meiner Testpartition probiere. Irgendwie spannend ja auch, was dann alles so passiert :-) Oder meinst du, dass das für mich als Kleinanwender mit vielen kleinen Arbeitsdateien dann gerade nicht geeignet ist?

Gruesse, Thomson

Erst mal vielen Dank Bernd

Hi Am Sonntag, 3. November 2002 23:19 schrieb Thomas Hertweck:

So, ich habe das Subject mal angepasst, da sich das Ganze doch etwas von der urspruenglichen Frage weg bewegt. Uebrigens reicht es, eine Email an die Liste zu schicken und nicht noch eine Kopie an mich direkt - ich lese die Liste mit, ist ja auch irgendwie der Sinn davon, oder?

auch das geschah im Eifer des Gefechts (muss immer erst den ursprünglichen Absender wie z.B. dich löschen, bevor's an die Liste raus geht und das vergesse ich manchmal :-)

Bernd Stäglich wrote:

...

Am Sonntag, 3. November 2002 22:11 schrieb Thomas Hertweck: [...] Tja, über Ext3 habe ich auch schon nachgedacht wegen des Journaling einerseits und seiner Bewährtheit andererseits und so ein Riesenanwender bin ich ja nun auch wieder nicht, sondern "nur" ein single user. Andererseits benutze ich ja nun gerade deswegen Reiser, weil das bezüglich vieler kleiner Dateien immer wieder über den grünen Klee gelobt wird.

Hmm, ich wuesste gerne einmal, wie sich diese Performance-Un- terschiede in der Praxis aeussern. Habe auch schon viel ueber diese ganze Sache gelesen, aber so richtig vorstellen kann man sich die Unterschiede kaum. Klar, ReiserFS benutzt ja ein voel- lig anderes Vorgehen als ext2, es basiert auf einem balanced tree, aber was merke ich davon im Alltag?

Das weiß ich auch nicht und ich bin ja nun auch nicht so der Techniker. Aber als ich von Windows aus völlig neu mit Linux anfing, dachte ich, nimm mal das Beste und Zukunftsträchtigste. Zu den Performance-Unterschieden hatte sich zu der Zeit nämlich mal das IX-Magazin geräuspert und sogar Tabellen dazu. Und JFS und XFS (auf jeden FAll JFS) wurde als für Linux noch ziemlich unausgereift abgetan trotz der theoretisch-technisch besseren Ansätze.

Ext3 bietet fuer mich den klaren Vorteil, rueckwaertskompatibel zu ext2 zu sein. Des- weiteren lassen sich bestehende ext2-Partitionen sehr leicht in ext3 umwandeln. Aber es basiert halt auf einer linearen Adressierung und kann daher von den Optimierungen wie unter ReiserFS keinen Gebrauch machen. Frueher oder spaeter wird wohl ext3 unter den Journaling Filesystemen eher auslaufen....

Genau das sehe ich nämlich auch so und deshalb will ich da eigentlich gar nicht erst mehr ran...

In der Vergangenheit habe ich mit ReiserFS leider schlechte Erfahrungen gemacht, was mich ein wenig abschreckt, es nun wie- der einzusetzen. Da mag sich aber doch einiges getan haben in letzter Zeit, und ich kenne auch viele Leute, die damit echt zufrieden sind.

Soll nicht jetzt was völlig Neues von Reiser rauskommen, was sogar so anders ist, dass man vom alten Reiser aus nicht drauf aufsetzen kann?

Nur leider gibt es halt doch hier und da (und auch auf dieser Liste) immer mal wieder Klagen ueber ReiserFS. Und wenn etwas passiert, dann scheint bei ReiserFS meist eine ganze Partition betroffen (verloren?) zu sein - zumindest er- wecken die Meldungen und Emails immer diesen Eindruck.

Wenn mir bei Staroffice 5.2 plötzlich Sachen verschwanden, insbesondere Mails, konnte ich es ja auch nicht beweisen, aber es war, nachdem was ich dann ja auch so gelesen hatte, so ein Gefühl. Natürlich können manche Unerfreulichkeiten tatsächlich auch auf SuSE selbst oder StarOffice selbst und gar nicht Reiser zurückzuführen sein. Aber gefühlsmäßig/vom technischen Ansatz her schätze ich mal anders.

...

...

Auf einigen Datenplatten setzen wir hier seit einer Weile auch xfs ein, weil wir es selbst mal testen wollten. Bisher gab es ueberhaupt keine Probleme damit. Das Filesystem bietet AFAIK bei grossen Dateien gewisse Performancevorteile. Aber bei den ganzen Journaling-Filesystemen streitet man sich ja eh, welches nun die erste Wahl ist :-)

Also am meisten würde mich dann tatsächlich XFS reizen. [...]

XFS (ist ja von SGI und in deren Servern unter IRIX auch schon lange Standard) wurde speziell fuer grosse Filesysteme und hohe Performance entworfen. Es ist wohl vom Aufbau her aehnlich zu ReiserFS, nur benutzt es keinen balanced tree sondern einen B+ tree. Der Vorteil von XFS ist sicher, dass es unter IRIX schon sehr lange Erfahrung damit gibt, wenngleich die Linux-Portierung natuerlich auch noch nicht so alt ist. Trotzdem habe ich bisher nur positive Erfahrungen damit gemacht - zur Zeit ist es hier auf einer 120GB Partition im Einsatz, die zum Speichern seismi- scher Daten dient (die sind mitunter recht gross :-) Und na- tuerlich auf unseren saemtlichen SGI-Servern ;-)

Also werde ich das dann mit XFS mal tun, wenn ich erst alles Andere wieder im Griff habe.

Gruesse, Thomson

Vielen Dank und gute Nacht Bernd

Hallo, On Sun, 03 Nov 2002, Thomas Hertweck wrote: [ext3 vs. reiserfs]

Hmm, ich wuesste gerne einmal, wie sich diese Performance-Un- terschiede in der Praxis aeussern.

Hantier mal in nem Verzeichnis mit, sagen wir, >20000 "Futzel"-Dateien ;)) $ mount | grep 'hda10\|hdb7' /dev/hdb7 on /data3 type reiserfs (rw) /dev/hda10 on /data2 type ext2 (rw) ### ["test"-dirs anlegen und Rechtevergabe ausgelassen] $ mkdir /data3/test/fs; mkdir /data2/test/fs; \ for p in /data3 /data2; do \ echo -en "testing on ${p}\ntouching:" >&2; \ time for i in `seq 1 20000`; do touch "${p}/test/fs/${i}"; done; \ echo -n "listing:" >&2; \ time ls "${p}/test/fs/" > /dev/null; \ echo -n "removing:" >&2; \ time rm -rf "${p}/test/fs/"; \ done ==== testing on /data3 touching: real 2m12.271s user 0m47.610s sys 1m22.150s listing: real 0m0.358s user 0m0.300s sys 0m0.040s removing: real 0m5.091s user 0m0.050s sys 0m4.440s testing on /data2 touching: real 2m36.415s user 0m48.920s sys 1m46.210s listing: real 0m0.220s user 0m0.190s sys 0m0.030s removing: real 0m1.347s user 0m0.030s sys 0m1.300s ==== Huch? Irjendwie hatte ich die Tests in der iX anders in Erinnerung ;) Achso, load war jew. knapp (bei reiser) bzw. gut (bei ext2) "1", CPU jew. unter 20% (mit nem AMD K7-500)... Und: ==== /var/log/boot.msg ==== <4>Using tea hash to sort names <4>reiserfs: using 3.5.x disk format <4>ReiserFS version 3.6.25 ==== Der 'tea hash' ist allerdings IIRC der langsamste der fuer reiserfs verfuegbaren hash-Funktionen, das mag obiges z.T. erklaeren... Ggfs. also z.B. selber "Benchmarks" laufen lassen... Aber -- auch aus eigener Erfahrung -- werde ich alles bis auf z.B. nen squid-cache, oder z.B. /var/cache/texmf/ o.ae. auf ext2/ext3 migrieren. Leider bin ich irgendwie noch nicht dazugekommen die e2fsprogs zu aktualisieren, so dass ext3 z.Z. noch nicht laeuft -- trotzdem hab ich erstmal schon wieder von reiser auf ext2 umgestellt. Und habe somit z.Z. u.a. ext2-Partitionen mit 25 (16.7 belegt) GB und 19.3 (17.4) GB... Naja, ich hab mittels tune2fs die fsck-Intervalle entzerrt, und ein fsck z.B. auf der 25G Partition braucht auch nur so ca. 5 min (eher weniger)... Da / und /home ziemlich klein sind und auch /usr mit ca. 6.4GB noch recht schnell ge'fsck't ist und ich den Rest bei Bedarf problemlos unmounten kann stoss ich von Zeit zu Zeit das fsck der grossen Partitionen per Hand an, und das evtl. fsck beim booten der kleineren stoert bei der schnellen HD nicht weiter: ==== $ cat /proc/ide/hda/model Maxtor 4D080H4 ==== # check_mountcount.sh Device: Cnt Max /dev/hda2: 25 30, mounted on / /dev/hda5: 14 20, mounted on /home /dev/hda7: 32 35, mounted on /usr /dev/hda8: 4 34, mounted on /newsw2 /dev/hda9: 21 32, mounted on /newsw3 /dev/hda10: 34 36, mounted on /data2 ==== Ah, bei der Gelegenheit: ==== # sync; sync; umount /data2; time fsck -fv /dev/hda10 Parallelizing fsck version 1.17 (26-Oct-1999) e2fsck 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09 [..] 276109 inodes used (8%) 428 non-contiguous inodes (0.2%) # of inodes with ind/dind/tind blocks: 20235/737/0 4491350 blocks used (67%) 0 bad blocks 260963 regular files 12353 directories 0 character device files 0 block device files 8 fifos 359 links 2776 symbolic links (2775 fast symbolic links) 0 sockets -------- 276459 files real 4m0.273s user 0m16.550s sys 0m6.310s # mount /data2 ===== Jo, "dat geit doch" :) Kann man "mal so eben", z.B. in der Zeit waehrend ich diese Mail tippere, durchlaufen lassen :) -dnh PS: (Jan Tr. faellt evtl. noch ne effektivere Loesung ein ;) ==== /root/bin/check_mountcount.sh ==== #!/bin/sh echo " Device: Cnt Max" for device in `mount | grep ext2 | cut -d' ' -f1`; do DATA=`tune2fs -l "$device" 2>/dev/null` CUR_CNT=`echo "$DATA" | awk '/^Mount count/{print $3}'`; MAX_CNT=`echo "$DATA" | awk '/^Max.*mount count/{print $4}'`; MNTPT=`mount | grep "$device" | awk '{print $3}'` printf "%12s: % 4i % 4i, mounted on %s\n" "$device" "$CUR_CNT" "$MAX_CNT" "$MNTPT"; done ==== -- Give a man fire, and he will be warm for a day, set a man on fire, and he will be warm for the rest of his life.

Hallo, On Mon, 04 Nov 2002, Jan Trippler wrote:

On Mon, 04 Nov 2002 at 05:49 (+0100), David Haller wrote: [...]

...

PS: (Jan Tr. faellt evtl. noch ne effektivere Loesung ein ;)

Jetzt hast Du mich provoziert ;-)

*g* [..]

==== /root/bin/check_mountcount.sh ==== #!/bin/sh mount -t ext2 | cut -d' ' -f1,3 | while read device mntpt do tune2fs -l "$device" 2>/dev/null | \ awk ' BEGIN { printf "%12s: %4s %4s\n", "Device", "Cnt", "Max" } /^Mount count/ { cur_cnt = $3 } /^Max.*mount count/ { max_cnt = $4 } END { printf "%12s: %4i %4i, mounted on %s\n", dev, cur_cnt, max_cnt, mnt } ' dev=$device mnt=$mntpt - done ====

Das war ungetestet, richtig? Ist ja schon recht gut, aber wieso gibts du die Spaltenkoepfe jedesmal mit aus? ;)

Nur 1 awk, kein grep, nur 1 mount - Sollte etwas resourcenschonender sein. Ich habe mir jetzt tune2fs nicht angeschaut, vielleicht kann man noch soweit optimieren, dass man ohne Schleife auskommt und alles mit einem tune2fs erledigen kann.

Nein, das geht nicht, tune2fs nimmt immer nur ein Device. ==== /root/bin/check_mountcount.sh ==== #!/bin/sh printf "%-10s %4s %4s %s\n" "device" "max" "cur" "mounted on" echo "---------- ---- ---- ----------···" mount -t ext2 | cut -d' ' -f1,3 | while read device mntpt do tune2fs -l "$device" 2>/dev/null \ | awk '/^Mount count/{cur=$3;} /^Max.*mount count/{max=$4;} END { printf "%-10s %4s %4s %s\n", dev, max, cur, mnt; }' \ dev="$device" mnt="$mntpt" - done ==== Und jep, das is deutlich flotter ;) -dnh PS: Aus dem Anlass hab ich noch nen anderes script[1] ueberarbeitet, das ist jetzt auch deutlich verbessert *bg* [1] 'dfall' summiert die Ausgabe von df auf (und formatiert neu, so dass auch mit '--block-size=1' und 90TB [2] noch alles passt ;) [2] ob awk damit noch rechnen kann weiss ich grad net ;) --

Wenn ich sie kennen wuerde, dann muesste ich nicht glauben. Hört sich an wie ein Bibelzitat. [in suse-talk]

On 03.11.2002 22:11, Thomas Hertweck wrote:

...

Ach so noch eine Abschlussfrage: Ext2, EXt3 sind mir von der Struktur her zu veraltet, deshalb benutze ich ja immer noch Reiser. Kann jemand schon ernsthaft JFS und XFS empfehlen? Tschuldigung: Ich weiß ja, dass das eigentlich schon wieder ein anderer Thread ist :-)

Was verstehst Du unter "veraltet"? Nur weil es ext2 schon lange gibt muss es ja nicht schlecht sein. In manchen Dingen bietet ReiserFS sicher Vorteile gegenueber ext2/ext3, aber ich habe damit leider schon sehr unangenehme Ueberraschungen erlebt. Mit

Erzähl mal. Bisher hatte ich noch keine Probleme und ReiserFS aus einer SuSE-7.3 auf einer Maschine seit ca. 1 Jahr laufen...

ext3, was bei uns standardmaessig auf Linux-Maschinen eingesetzt wird, sind wir eigentlich sehr zufrieden.

Gilt das auch für das ext3 aus der SuSE-8.1 oder vorherigen Versionen? Ralf

Hy, Am 02/11/03@21:23 schrieb advreg: ^^^^^^ :(

Ach so noch eine Abschlussfrage: Ext2, EXt3 sind mir von der Struktur her zu veraltet, deshalb benutze ich ja immer noch Reiser. Kann jemand schon ernsthaft JFS und XFS empfehlen?

Ich benutze seit ca. 6 Monaten ein 100 GB xfs LV [1]. Ich mache auf dem volume Videobearbeitung und es wird schon einiges bewegt. Wie performant xfs bei kleines files (Webserver, Newsserver) ist weiss ist nicht. Du findest aber bestimmt benchmarks im Netz. Auch kenne ich eine Reihe von Leuten die xfs benutzen, ohne das ich jemals von Problemem gehört habe. Mit Reiser hatte ich auch schon Probleme, wo mir nur noch ein Hilfeschrei auf der reiser Liste half. Wie man mir dort erklärte hatte SuSE am Quelltext geändert um irgenwas PPC kompatibel zu bekommen. JFS kenne ich nicht. Es scheint, dass SuSE zur Zeit irgendwelche Probleme mit LVM hat, denn das kam beispielsweise heute über die lokale LUG: ---schnipp--- lvm und SuSe ab 8.0 ist ne mittlere Katastrophe! Weder die Suse 8.0 noch 8.1 sind in der Lage mit LVM Rawdisks umzugehen. Ich hatte hier nen LVM-Verbund mehrerer Platten. Eine war ne Rawdisk ohne Partition-Table: LVM kann bekanntlich damit umgehen und die ganze Platte nutzen. Keine von den Susis war in der Lage, die ganze Platte (die,ohne Partitionen) als LVM-Laufwerk zu erkennen. ---schnapp--- [1] unter debian -- bye maik