Stefan Eggert schrieb:

...

Das hätte ich mir fast denken können. Check das Filesystem durch. Da hat sich reiserfs zerhauen! Ob dahinter ein Festplattendefekt steckt, kann man nicht wissen.

Und wieder ein grund bei EXT2 zu bleiben....

Zumindest ein Grund gegen ReiserFS. Ich habe da so meine Abneigungen. Zumindest seid die Alternativen auch produktionsreif sind. Von IBMS JFS oder dem XFS habe ich solche stories noch nicht gehört. Dies kann natürlich an der geringeren Verbreitung liegen oder eben daran, dass diese Probleme dort nicht existierten. Ich setze XFS ein und bin voll zufrieden. ext3 mag ich selbst nicht. Das sieht mir zu sehr nach Workaround aus. So nach dem Motto: Dann basteln wir mal einfach da noch um das ext2 etwas drumherum. Mag ich nicht. Wobei mir der Ansatz der Smartupdates von FreeBSD deutlich besser gefällt, als dieses Journaling. Aber das steht unter Linux ja nicht so zur Verfügung. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Hallo Stefan! Stefan Eggert schrieb:

EXT3 mag ich auch nicht unbedingt, wie Du schon sagtest, es ist einfach was rumgebastelt worden. Ich selber setze (nach einem großen Raiser Ausfall am Server) nur noch ext2 ein, habe mich damals kaputt geärgert. ext2 ist nunmal eines der erfahrensten Filesysteme unter Linux, und ich denke, auch in Zukunft werde ich daran halten.

Für / auf jeden Fall, da dieses Verzeichnis nicht so gross ist. Aber meine Daten werde ich nicht auf ein ext2 legen. Selbst wenn nie etwas schiefläuft kommt dann alle x Boots ein check. Und 100 GB zu prüfen dauert mir einfach viel zu lange ... Oder hast Du diese Problematik irgendwie anders gelöst? Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Hallo, [Konrads Mail ist hier noch nicht aufgeschlagen] On Thu, 12 Jun 2003, Stefan Eggert wrote:

Konrad Neitzel wrote:

...

Stefan Eggert schrieb:

...

EXT3 mag ich auch nicht unbedingt, wie Du schon sagtest, es ist einfach was rumgebastelt worden.

Das ist fuer micht nicht per se ein Nachteil. ext2 ist "erweiterbar" (siehe z.B. das Thema ACL bzw. die Definitionen der Datenstrukturen). Rasierfs hat diesen "Spitznamen" nicht zu unrecht. Es scheint nach wie vor alles andere als robust zu sein, mal abgesehen von den FS-Tools.

...

Für / auf jeden Fall, da dieses Verzeichnis nicht so gross ist.

Ack. Bei mir braucht ein fsck auf / unter 5s oder so (1 GB FS / <200 MB belegt). /home mit 3 GB / 2.5 GB belegt ist auch ext2 und ein fsck dauert auch nicht stoerend lange. Auf allen anderen Partitionen verwende ich ext3.

...

meine Daten werde ich nicht auf ein ext2 legen. Selbst wenn nie etwas schiefläuft kommt dann alle x Boots ein check. Und 100 GB zu prüfen dauert mir einfach viel zu lange ... Oder hast Du diese Problematik irgendwie anders gelöst?

Ich habe 1. die Intervalle an mein haeufiges booten angepasst, 2. kann man das fsck auch ausschalten. root@slarty[0]:~ (0)# check_mountcount.sh device type max cur mounted on ---------- -------- ---- ---- ----------··· /dev/hda2 ext2 30 4 / /dev/hda5 ext2 25 2 /home /dev/hda7 ext3 35 6 /usr /dev/hda8 ext3 34 19 /newsw2 /dev/hdb7 ext3 43 8 /data /dev/hdb8 ext3 38 23 /vardata /dev/hda9 ext3 42 3 /newsw3 /dev/hda10 ext3 46 41 /data2 /dev/hdc2 ext3 27 6 /data3 /dev/hdb6 ext3 39 1 /doc Das script "check_mountcount.sh" (s.u.) rufe ich mehr oder weniger regelmaessig auf, und checke dann die FS, die fast faellig sind. Allerdings sind die mount-limits so verteilt, dass i.d.R. nur jew. eine Partition gecheckt werden muss, was dann jew. < 1 min dauert und nicht sonderlich stoert, selbst wenn's grad eher ungelegen ist. Bis auf / und /data (da liegt z.Z. /var) kann ich alle Partitionen auch im laufenden Betrieb umounten oder (/home und /usr) zumindest ohne Probleme ro-remounten. Und wie gesagt, mit ext3 kann man den fsck auch deaktivieren (-> aber bitte nochmal in der ext3 Doku nachlesen), dann wird beim mounten wie bei rasierfs das Journal bei mount eingespielt falls noetig (nach nem crash z.B.).

Meine größter Datenserver hat 4*80 GB, und das könnte laaaaange Zeit in anspruch nehmen.

s.o. Die fsck's kann man entzerren. Achso: Meine Partitionen sind u.a. 16 GB (15.3 GB belegt), 20 GB (16.3 GB) und 26 GB (20.1 GB) gross, aber auch bei denen stoert ein (einzelnes) fsck nicht weiter. Gesamt hab ich z.Z. 115 GB / 76 GB belegt (teil normal nicht gemountet). Achso, die Intervalle fuer die fscks muss man eben anpassen, ich boote z.B. mind. 1mal taeglich[1], obige Intervalle haben sich bei mir bewaehrt, es wird (je nach Partition) ca. 1-2 mal pro Monat ein fsck faellig. Je nach Bedarf/Boot-Verhalten sollte man eben groessere oder kleinere Limits setzen (siehe 'man tune2fs'). HTH, -dnh PS: Ja, meine Partitionierung bzw. eher die mountpoints sind "etwas" defekt, aber das hat sich ueber die inzwischen 4 Jahre die meine Installation laeuft einfach so ergeben, schliesslich wanderten die Daten ueber mehrere Festplatten und Partitionen... Die HD, auf der ich urspruenglich installierte ist IIRC schon seit 2 Jahren nicht mehr eingebaut, aktuell wird IIRC fuer / die 4te HDD verwendet... Und meist war es sehr eng vom Platz her, vieles ist also mehr oder weniger "wild" mit symlinks umgebogen (z.B. /var nach /data/var (und unter /var ist wieder einiges auf wieder andere Partitionen rausgelinkt *lol*), tja, is halt ein gewachsenes Bastelsystem, das u.a. einen gescheiterten und geflickten glibc-update Versuch hinter sich hat ;) Oh, und zwischendurch wurden u.a. CPU, MoBo und RAM komplett ausgetauscht -- und die FS von nur ext2 ueber groesstenteils reiserfs zu nun groesstenteils ext3 migriert... Mein System zeigt also, wie flexibel und robust ein Linux sein kann, Windows hab ich (mit eher weniger bastelei) mindestens alle 3 Monate neu installieren muessen... [1] nach dem Aufstehen wird die Kiste hochgefahren, vor'm schlafengehen runtergefahren ;) PPS: Hier o.g. script, evtl. sollte man statt dem 'mount' ein 'cat /proc/mounts' verwenden, da muesste man das script ein wenig anpassen. ==== /root/bin/check_mountcount.sh ==== #!/bin/bash printf "%-10s %-8s %4s %4s %s\n" "device" "type" "max" "cur" "mounted on" echo "---------- -------- ---- ---- ----------···" mount | awk '/ext[23]/{print $1" "$3" "$5;}' | while read device mntpt type do tune2fs -l "$device" 2>/dev/null \ | awk '/^Mount count/{cur=$3;} /^Max.*mount count/{max=$4;} END { printf "%-10s %-8s %4s %4s %s\n", dev, t, max, cur, mnt; }' \ dev="$device" mnt="$mntpt" t="$type" - done ==== -- Yep, definately trees, I remember them from last time I was let loose in the big blue room. -- Rob Adams in the SDM

Am Don, 2003-06-12 um 08.34 schrieb Konrad Neitzel:

Hallo Stefan!

Stefan Eggert schrieb:

...

EXT3 mag ich auch nicht unbedingt, wie Du schon sagtest, es ist einfach was rumgebastelt worden. Ich selber setze (nach einem großen Raiser Ausfall am Server) nur noch ext2 ein, habe mich damals kaputt geärgert. ext2 ist nunmal eines der erfahrensten Filesysteme unter Linux, und ich denke, auch in Zukunft werde ich daran halten.

Für / auf jeden Fall, da dieses Verzeichnis nicht so gross ist. Aber meine Daten werde ich nicht auf ein ext2 legen. Selbst wenn nie etwas schiefläuft kommt dann alle x Boots ein check. Wenn *das* dein Problem ist, schalt die Checks doch ab!

[vgl. man tune2fs, Optionen -c und -i]

Und 100 GB zu prüfen dauert mir einfach viel zu lange ... Oder hast Du diese Problematik irgendwie anders gelöst? Gelöst? Nein, "ge-work-arounded" ja.

Ich verwende ext3, sowie statt einer 100GB Partition, mehrere kleinere.Partitionen mit jeweils unterschiedlich grossen "MaxMountCounts". Das hat zur Folge, dass * die "regularen" (MaxMountCount bedingten) Checks in der Regel nicht alle gleichzeitig auftreten * im Fall von Systemabstürzen in der Regel nur ein Rückspielen der Journals notwendig ist. * im Fall von schweren Systemabstürzen in der Regel "echte e2fscks" nur auf einer sehr kleinen Anzahl von Partitionen notwendig ist. Davon abgesehen, habe ich mit ext3 keine Probleme. Klar, ext3 ist ebenso wie andere FSe auch von Bugs betroffen (Darunter kürzlich auch mal ein recht schwerwiegender), doch * von xfs/jfs u.a. hält mich (wie auch von Dir in einere anderen Mail angedeutet) die - geringe Verbreitung und damit fehlende Erfahrungswerte. - mässige Integration in die Distributionen ab. * Bei reiserfs war ich vor einiger Zeit von massiven Problemen betroffen, genauso wie ich den Eindruck habe, dass Reiserfs sehr viel empfindlicher auf FS-Fehler reagiert als ext2/ext3. Ralf

Am Donnerstag, 12. Juni 2003 07:49 schrieb Stefan Eggert:

Und wieder ein grund bei EXT2 zu bleiben....

Naja, bei EXT3 hatte ich das Phänomen auch schon mal ... Backup, formatieren der Partition und zurücksichern, dann lief der Spaß wieder. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de