Martin Schröder martin@oneiros.de writes:

Am 5. September 2010 21:25 schrieb Dieter Kluenter dieter@dkluenter.de:

...

Wenn du viele große Dateien hast, Bilder etc. und moderate Schreiboperationen, nimm xfs, sonst ext4.

xfs kann ich nicht mehr empfehlen: https://bugzilla.novell.com/show_bug.cgi?id=631296

Diese recht langsamen Schreiboperationen kann ich bestätigen, die habe ich mit OpenLDAP auch, deshalb schrieb ich ja 'moderate Schreiboperationen'. Trotzdem kann man xfs empfehlen, denn es gibt einige Features, wie das Auslagern des Journals, Access Control usw. auf die man nicht verzichten möchte. Hier ist ein Benchmark-Test http://www.pro-linux.de/artikel/2/224/das-dateisystem-ext4.html

-Dieter

Heinz Diehl htd@fancy-poultry.org writes:

On 06.09.2010, Dieter Kluenter wrote:

...

Diese recht langsamen Schreiboperationen kann ich bestätigen, die habe ich mit OpenLDAP auch, deshalb schrieb ich ja 'moderate Schreiboperationen'.

Ich benutze XFS seit ewigen Zeiten und kann das nicht bestaetigen. Kann bitte mal jemand mit "nobarrier" mounten und nochmal testen?

Das hatte ich schon, ohne Erfolg. Ich vermute, dass die geringe Schreibleistung bei OpenLDAP, präziser BerkleyDB, darauf zurückzuführen ist, dass eine bestehende Datei, nämlich die bdb Database, durch häufige Schreiboperationen ständig verändert wird, wenn dann noch mehrere parallele Schreiboperation erfolgen: Modifikationen von Einträgen, Löschen von Einträgen und neue Einträge hinzufügen, dazu entsprechende parallele Leseoperationen, dann verzögert sich die Schreiboperation erheblich. Diesen Leistungsverlust habe ich mit ext2 nicht.

-Dieter

Hallo Dieter,

On Sunday 05 September 2010 21:25:35 Dieter Kluenter wrote:

Wenn du viele große Dateien hast, Bilder etc. und moderate Schreiboperationen, nimm xfs, ...

Beim Loeschen vieler Dateien ist XFS in der Defaulteinstellung schnarchlahm.

sonst ext4

Inzwischen mein Favourit.

In einer Testumgebung habe ich ich vor ca. 1 Jahr btrfs getestet, ...

Damit hatte ich in der Version die bei der 11.3 dabei ist bei voll werdenden FSs Probleme. Beim einem git-Kernel ist das aber weg. MeeGo will das wohl auch einsetzen, aber fuer einen Desktop wuerde ich das mal noch nicht riskieren wollen, speziell da deses FS IMHO offiziell noch nicht als stabil deklariert wurde.

Roman

Hallo Bernd,

Lentes, Bernd schrieb:

Andere Frage: in einer älteren Linux-Magazin hatte ich gelesen, daß man ext3 online vergrößern und verkleinern kann, xfs online nur vergrößern. Das deckt sich aber nicht mit meinem Kenntnisstand. Ext3 ist IMHO nur mit einem patch online resizeable. Wisst Ihr genaueres ?

soweit mir bekannt ist, macht ein Online-Resizing nur Sinn bei einem LVM System. Da habe ich das Online-Growing bereits ausprobiert:

[1], [2]

Soweit wie im Link [3] beschrieben reicht mein Kenntnisstand. Du wirst IMHO kein Tool finden, was Dir eine richtige Partition online vergrößert...

[1]http://jbopensrc.wordpress.com/2007/10/10/growing-a-lvm2-ext3-partition/

[2]http://tldp.org/HOWTO/LVM-HOWTO/extendlv.html

[3]http://www.linuxhaven.de/dlhp/HOWTO/DE-LVM-HOWTO-4.html#ss4.13

Hi Bernd,

On Mon, 13 Sep 2010, 18:59:25 +0200, Lentes, Bernd wrote:

[...]

...

[1]http://jbopensrc.wordpress.com/2007/10/10/growing-a-lvm2-ext3-partition/

Es ist mir schleierhaft, wie der in genanntem link mit resize2fs online eine Partition vergrößert. Bei mir sagt resize2fs:

pc53082:/mnt # resize2fs /dev/sdb1 resize2fs 1.38 (30-Jun-2005) /dev/sdb1 is mounted; can't resize a mounted filesystem!

...

[2]http://tldp.org/HOWTO/LVM-HOWTO/extendlv.html

das deckt sich mit meinem Kenntnisstand. man ext2online sagt: "To be able to use ext2online, you need to have the Online ext2 resize support (CONFIG_EXT2_RESIZE) feature enabled in the kernel (after applying the appropriate patch for the 2.x series of kernels)." Wie kann ich rauskriegen, ob bei meinem SLES 10 dieses feature im kernel enabled ist, und ob ich diesen patch habe ? Hat jemand Erfahrungen mit ext2/3 online vergrößern ?

Auf einem hinreichend aktuellen SLES 10 (seit SP2 soweit ich weiss), geht das; du musst auf dem alten System lediglich ext2online nutzen, denn resize2fs konnte auf dem alten Kernel wirklich nur offline resizen.

Bernd

HTH, cheers.

l8er manfred

...

Auf einem hinreichend aktuellen SLES 10 (seit SP2 soweit

ich weiss),

...

geht das; du musst auf dem alten System lediglich

ext2online nutzen,

...

denn resize2fs konnte auf dem alten Kernel wirklich nur offline resizen.

...

Bernd

HTH, cheers.

l8er manfred

Hmm, hab's gerade noch einmal ausprobiert:

pc52842:/etc # resize2fs /dev/vg1/lv1 resize2fs 1.38 (30-Jun-2005) /dev/vg1/lv1 is mounted; can't resize a mounted filesystem!

mit "zypper se e2fsprogs" krieg' ich auch kein aktuelleres e2fsprogs angeboten.

Das o.g. System wird regelmäßig mit den aktuellen patches versorgt.

Das Komische ist, daß Novell selbst schreibt (http://www.novell.com/documentation/sles10/stor_evms/?page=/d ocumentation/sles10/stor_evms/data/resizeincr.html), mit resize2fs wäre ein resizen im gemounteten Zustand möglich.

Wieso klappt das nicht bei mir ?

Noch was: Lt. Sourceforge (http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.36) kann e2fsprogs das mind. seit 1.36. Ich habe aber 1.38:

pc52842:/etc # rpm -qf `which resize2fs` e2fsprogs-1.38-25.36.1

Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Glaub's mir, auf dem SLES 10 heisst das Tool der Wahl "ext2online"; erst seit SLES 11 geht das online auch mit "resize2fs"!

Hallo Manfred,

Ich glaub's Dir ja, darum geht es nicht. Es ist nur seltsam, daß Novell selbst schreibt, es ginge bei SLES 10 mit resize2fs: http://www.novell.com/documentation/sles10/stor_evms/?page=/documentation/sl...

Und die Option "CONFIG_EXT2_RESIZE" ist bei mir nicht gesetzt, dann dürfte ext2online auch nicht funktionieren. Ich guck 'mal, ob ich bei mir ein LV finde, an dem ich das ungefährdet austesten kann.

Bernd-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Montag, 13. September 2010 schrieb Lentes, Bernd:

...

Auf einem hinreichend aktuellen SLES 10 (seit SP2 soweit ich weiss), geht das; du musst auf dem alten System lediglich ext2online nutzen, denn resize2fs konnte auf dem alten Kernel wirklich nur offline resizen.

...

Bernd

HTH, cheers.

l8er manfred

Hmm, hab's gerade noch einmal ausprobiert:

pc52842:/etc # resize2fs /dev/vg1/lv1 resize2fs 1.38 (30-Jun-2005) /dev/vg1/lv1 is mounted; can't resize a mounted filesystem!

mit "zypper se e2fsprogs" krieg' ich auch kein aktuelleres e2fsprogs angeboten.

Das o.g. System wird regelmäßig mit den aktuellen patches versorgt.

Das Komische ist, daß Novell selbst schreibt (http://www.novell.com/documentation/sles10/stor_evms/?page=/documentation/ sles10/stor_evms/data/resizeincr.html), mit resize2fs wäre ein resizen im gemounteten Zustand möglich.

Wieso klappt das nicht bei mir ?

Vermutlich historische resize2fs Version. Per Patches bekommst du normalerweise keine neuere Versionen und somit neue Features. Da werden nur Bugs gefixt . 11.3 kommt mit Version "1.41.11 (14-Mar-2010)".

Hallo,

Am Mon, 13 Sep 2010, Lentes, Bernd schrieb:

das deckt sich mit meinem Kenntnisstand. man ext2online sagt: "To be able to use ext2online, you need to have the Online ext2 resize support (CONFIG_EXT2_RESIZE) feature enabled in the kernel (after applying the appropriate patch for the 2.x series of kernels)." Wie kann ich rauskriegen, ob bei meinem SLES 10 dieses feature im kernel enabled ist, und ob ich diesen patch habe?

zgrep CONFIG_EXT2_RESIZE /proc/config.gz

HTH, -dnh

Verwende ebenfalls ReiserFS, weil ich es gewohnt bin. Habe nie irgendwelche Benchmarks gemacht, also keine Ahnung über verhältnismässige Geschwindigkeit.

Ich arbeite mit sehr grossen Dateien (30 bis 500 MB) und auch mit vielen kleinen (ein paar Kilos), sowie MySQL-Datenbanken. Probleme gabs nur, wenn die Disk zu voll wurde (weit über 90%).

Mehrere Stromausfälle schadlos überstanden.

Gruss

Daniel

On Monday 06 September 2010 14.53:59, Sascha P. wrote:

Hallo Bernd

Also ich verwende seit Jahren (mehr oder weniger aus Gewohnheit) das ReiserFS und kann darüber eigentlich nur Gutes berichten. Gut, irgendwelche Performance-Tests hab ich mir schon länger nicht mehr angesehen und es mag sein, dass es nicht mehr up-to-date ist. Für meine Zwecke war es jedoch immer performant genug, auch den einen oder anderen Stromausfall hat es ohne nennenswerte Probleme überstanden.

Wenigstens etwas, was Hans Reiser meiner Meinung nach gut gemacht hat - wenn ich mich auch von gewissen anderen Sachen aus seinem Leben deutlich distanziere (aber das war ohnehin nicht Thema deines Postings und ist damit OT).

HTH, Sascha

Am 05.09.2010 20:36, schrieb Lentes, Bernd:

...

Hallo ML,

Ich muss demnächst zwei Maschinen aufsetzen. Das letzte Mal habe ich noch SuSE 10.2 benutzt. Ist 'ne Zeit lang her. Die neuen Maschinen kriegen entweder 11.3 oder SLES 11. Ich habe mit ext4 oder btrfs keine Erfahrung. Ist der Einsatz sinnvoll ? Einsatzzweck ist in beiden Fällen eine Arbeitsstation, ggf. mit Datenbank und Webserver, allerdings höchstens mit einigen 100 Zugriffen am Tag.

Bernd

Hallo,

Könnt ihr bitte das TOFU lassen?

Am Mon, 06 Sep 2010, Daniel Bauer schrieb:

Verwende ebenfalls ReiserFS, weil ich es gewohnt bin. Habe nie irgendwelche Benchmarks gemacht, also keine Ahnung über verhältnismässige Geschwindigkeit.

Ich arbeite mit sehr grossen Dateien (30 bis 500 MB) und auch mit vielen kleinen (ein paar Kilos), sowie MySQL-Datenbanken. Probleme gabs nur, wenn die Disk zu voll wurde (weit über 90%).

Mehrere Stromausfälle schadlos überstanden.

On Monday 06 September 2010 14.53:59, Sascha P. wrote:

...

Also ich verwende seit Jahren (mehr oder weniger aus Gewohnheit) das ReiserFS und kann darüber eigentlich nur Gutes berichten. Gut, irgendwelche Performance-Tests hab ich mir schon länger nicht mehr angesehen und es mag sein, dass es nicht mehr up-to-date ist. Für meine Zwecke war es jedoch immer performant genug, auch den einen oder anderen Stromausfall hat es ohne nennenswerte Probleme überstanden.

Ihr seid beide Glückspilze. Reiserfs hat seine Spitznamen (von mir: Reißwolffs, von anderen: Rasierfs) nicht ohne Grund bekommen.

Testet mal in ner VM ein Reiserfs in dem ein Reiserfs-Image liegt, beschädigt das FS und versucht dann mit reiserfsck (--rebuild-tree ;P) das FS wiederherzustellen ... Viel Spaß!

Und dann das "lustige" Verhalten von Reiserfs gelegentlich Dateien unlöschbar zu korrumpieren (z.B. erkennbar an ganz seltsamen Dateirechten, das wurde evtl. später noch behoben)...

Auch bei HW-Problemen ist Reiserfs (wie XFS auch, das aber aus anderen Gründen) weniger robust als ext2/3/4. BTDT, lost a lot of files.

Ext4 / btrfs werde ich dann auch mal testen, aber z.Z. ist mir Robustheit wichtiger als das letzte Quentchen Geschwindigkeit. Speziell "wie schnell ist ein mkfs"-Benchmarks halte ich für hochgradig praxisfern[1].

Kurzum: Reiserfs taugt(e) für newsspools usw., aber nicht für wichtige Daten.

Ich selber würde gern mal zfs testen ...

-dnh, nur noch mit ext2/ext3 (noch nicht ext4) unterwegs, die haben bei nem typischen FS-Füllstand von 95-100% (nur die /-Partition ist meist <90% voll) in den letzten 10 Jahren die derbsten HW-bedingten Abstürze (teilweise hing die Kiste so, daß nichtmal der Reset-Taster noch tat!) schadlos überstanden, und bei Festplattendefekten waren nur die unmittelbar auf den defekten Sektoren liegenden Dateien betroffen (der Superblock wird zum Glück und aus gutem Grund bei ext2/3 mehrfach redundant an verschiedenen Stellen der Partition gespeichert -- das hat mir mehr als einmal das FS gerettet!).

[1] ok, es mag Sonderfälle geben, wo beim booten "on-the-fly" ein temp-FS o.ä. erzeugt wird. Aber da hat man's wohl eh mit noch ganz anderen Dingen zu tun.

Hallo,

Am Mon, 06 Sep 2010, Martin Hofius schrieb:

Am Montag, 6. September 2010 schrieb David Haller:

...

Ihr seid beide Glückspilze. Reiserfs hat seine Spitznamen (von mir: Reißwolffs, von anderen: Rasierfs) nicht ohne Grund bekommen.

da gibt es noch mehr Glückpilze... bei mir hat reiserfs auch viele Jahre klaglos funktioniert - bevor ich dann zum Umstieg von 9.3 auf 10.3 "gezwungen" wurde und dann aufgrund eben solcher Berichte dann auf ext3 umgestiegen bin. Aber trotzdem - auch bei mir hat reiser nie auch nur eine Datei erkennbar beschädigt, bei Stromausfällen war das FS immer sehr schnell wieder hergestellt... Und bei ext 3 nerven die (bekannten, aber dann doch unerwarteten) FS-Checks nach 60 Tagen einfach nur, weil es so lange dauert. Da war reiser doch irgendwie wesentlich flotter.

Das, was ext2/3 macht reiserfs nur wenn du explizit per Hand reiserfsck aufrufst, und anfangs war reiserfsck noch unbrauchbar. Du kannst bei ext3 ganz einfach das gleiche Verhalten bekommen (so hab ich das bei mir übrigens), indem du einfach in der fstab 0 in die letzte Spalte schreibst. Du bekommst dann nach überschreiten des mount-counts / der Tage seit dem letzten fsck nur noch nen Hinweis beim mount:

<4>EXT3-fs warning: maximal mount count reached, running e2fsck is recommended

Das, was du bei reiserfs als fsck bezeichnest ist keiner, und das macht ext3 auch automatisch und in Sekundenschnelle, wenn das FS nicht sauber umounted wurde ("Replaying Journal").

Und ja, ich weiß, daß reiserfs bei vielen jahrelang sauber funktionierte und funktioniert. Aber das "selber verheddern" kenn ich eben nur von reiserfs und das gab's hier in der ML auffällig oft.

...

Und dann das "lustige" Verhalten von Reiserfs gelegentlich Dateien unlöschbar zu korrumpieren (z.B. erkennbar an ganz seltsamen Dateirechten, das wurde evtl. später noch behoben)...

nie bei mir vorgekommen.

Findet sich im Archiv ;)

...

-dnh, nur noch mit ext2/ext3 (noch nicht ext4) unterwegs, die haben

ich habe ext4 auf unseren Notebooks (mit OS 11.2) ... ab und zu sind da irgendwelche plasma-Dateien korrupt, aber ob das an ext4 liegt oder doch eher an KDE4.x?

KDE4. Oder kannst du die Dateien auch mit cat / dd nicht mehr auslesen (sofern du Leserechte hast, ggfs. setzen, bei Reiserfs (s.o.) ging das aber nicht, da hat sich das FS verheddert)

...

Sektoren liegenden Dateien betroffen (der Superblock wird zum
Glück und aus gutem Grund bei ext2/3 mehrfach redundant an
verschiedenen Stellen der Partition gespeichert -- das hat mir
mehr als einmal das FS gerettet!).

ist das bei ext4 nicht mehr so?

AFAIK schon, aber ich hab ext4 halt noch nicht angeschaut ;)

-dnh

Hallo,

Am Mit, 08 Sep 2010, Martin Hofius schrieb:

also zusammenfassend: reiserfs: nicht unperformant (speziell sehr gut bei vielen kleinen Dateien), aber Berichte über Fehlverhalten mit Datenverlust und faktisch fehlende Weiterentwicklung bzw. Korrekturen

ext2/ext3: ausgereift und stabil auch bei Hardwareausfällen, Performance in den meisten Fällen nicht schlecht (aber etwas lahm bei Verzeichnissen mit extrem vielen Dateien)

Jep. Allerdings: wenn's ganz blöd läuft verreckt auch ein ext2/3 bei Hardwarefehlern komplett. Da muß es aber schon arg doof laufen (ist mir IIRC einmal passiert, das andere Mal tat die Platte schlicht keinen Mucks mehr, da konnte ext3 dann auch nix für). Generell ist ext3 eben recht redundant und robust (als FS, einzelne Dateien erwischt es natürlich, wenn die Sektoren über den Jordan sind, oder man darf sie in lost+found zusammensuchen, wenn z.B. das Verzeichnis hops geht). Was das FS als solches aushält ist erstaunlich. Ich hatte hier in den letzten 2 Jahren diverse (HW- / Absturz-während-I/O- bedingte-[1]) Fehler im FS (meist falsche Inode-Counts usw.), einmal hat sich wohl der Superblock verabschiedet ... e2fsck mit -b 65536 oder so (war mit sparse super feature, daher stimmte der Vorschlag 8192 (-3?) nicht ;) ging's dann und alle Dateien waren noch da :) Jedenfalls bin ich von der Robustheit von ext2/ext3 aus mittlerweile über 12 Jahren Erfahrung mit immer 4 Platten (seit ein paar Jahren deutlich mehr, aktuell sind 14 in Betrieb, zus. >= 15 TiB (echten, formatierten!)) (und nem Abstecher zu reiserfs) überzeugt.

BTW: Einen Nachteil hat ext3 ggü. ext2: es geht prinzipbedingt kein 'undelete' ;)

ext4: Performance wohl etwas besser als bei ext3, noch nicht so ausgetestet, in der Theorie vermutlich ähnlich stabil wie ext3

Scheint mir auch so. ext4 muß für mich noch ein bissl "abhängen" ;) Ich will es aber bald mal testen (und quälen ;P)

der Rest: kann ggf. sein bei besonders großen Dateien oder anderen Spezialfällen, wird aber zumindest unter OS nicht so gut getestet (bzw. so oft verwendet...) wie ext3 / ext4 - also eher für Leute, die ganz genau wissen, was sie damit tun ;-)

Im Moment ja. Wenn XFS (optional?) nicht mehr Dateien ausnullt, die bei nem Absturz grad im Zugriff waren (aus Sicherheits- und FS-Konsistenzgründen) scheint auch XFS unter Linux ausgereift (und AFAIK dann auch robust). XFS ist auch einiges komplexer als ext3[2].

btrfs scheint sich sehr gut zu entwickeln.

ZFS ist (AFAIK) unter Linux wohl nicht ganz so "sauber" integriert und/oder hat AFAIR irgendwelche Macken, unter openSolaris aber wohl sehr robust. Leider weiß man nicht, wie's mit openSolaris (und ZFS) weitergeht, nachdem Oracle Sun gekauft hat ...

JFS scheint eher ein Exot zu sein, und der Rest sind weitgehend FS für "Sonderfälle" wie Flash (ohne wear-leveling), für RAM-FS, CDROM, DVD (-RAM), usw...

IMO ist ext3 noch der beste Default (da ein guter Allrounder, robust und gut getestet). ext4 wird wohl bald, btrfs braucht noch... reiserfs ist wohl ein Zombie, und reiserfs4? öhm, keine Ahnung ;)

HTH, -dnh, der (bei 2.4.x) auch mal in den Quelltexten von ext2, reiserfs und ext3 gestöbert hat ;)

PS: bei ext3 war ich auch recht lange vorsichtig und habe es erst recht spät verwendet ;)

[1] wenn sich die HW so hart weghängt, daß IIRC nichtmal der Resettaster mehr tut, IIRC mußte ich die Kiste per Powerknopf ausschalten (oder sogar per Netzteil) ...

[2] vgl. nur die Größe der Module, äh, Mift, ext3 is ja inzwischen fest im Kernel ... Ich guck mal in irgendwelchen 11.x ISOs o.ä.

Servus Heinz,

Heinz Diehl, Mittwoch 08 September 2010:

XFS nullt Files aus, das stimmt, aber nicht bei einem crash, sondern bei einfachem, regulaerem Loeschen.

Ich bin kein FS-Spezialist, aber ich glaube, hier täuschst Du Dich. Soeben ausprobiert - eine knapp 70 GB große Datei (ein kvm-Image) habe ich in wenigen Sekunden gelöscht bekommen. Mein Plattenstapel ist meine ich keinesfalls schnell genug, in dieser kurzen Zeit 70 GB wegzuschreiben.

Gruß!

...

...

...

Ihr seid beide Glückspilze. Reiserfs hat seine Spitznamen (von mir: Reißwolffs, von anderen: Rasierfs) nicht ohne Grund bekommen.

da gibt es noch mehr Glückpilze... bei mir hat reiserfs auch viele Jahre klaglos funktioniert - bevor ich dann zum Umstieg von 9.3 auf 10.3 "gezwungen" wurde und dann aufgrund eben solcher Berichte dann auf ext3 umgestiegen bin. Aber trotzdem - auch bei mir hat reiser nie auch

...

...

kannst bei ext3 ganz einfach das gleiche Verhalten bekommen (so hab ich das bei mir übrigens), indem du einfach in der fstab 0 in die letzte Spalte schreibst. Du bekommst dann nach überschreiten des mount-counts / der Tage seit dem letzten fsck nur noch nen Hinweis beim mount:

<4>EXT3-fs warning: maximal mount count reached, running e2fsck is recommended

danke für den Hinweis - werde ich ggf. auch so einstellen. Oder vielleicht auch nicht - irgendwann demnächst kommt sowieso neue Hardware und dann auch OS 11.2, vielleicht geht der Rechner dann eher in den Ruhezustand als heruntergefahren zu werden. Dann hätte sich das mit dem mount-count faktisch erledigt.

...

Das, was du bei reiserfs als fsck bezeichnest ist keiner, und das macht ext3 auch automatisch und in Sekundenschnelle, wenn das FS nicht sauber umounted wurde ("Replaying Journal").

klar - schon oft genug gesehen...

...

Und ja, ich weiß, daß reiserfs bei vielen jahrelang sauber funktionierte und funktioniert. Aber das "selber verheddern" kenn ich eben nur von reiserfs und das gab's hier in der ML auffällig oft.

ok, es gibt halt die persönliche Statistik (mangels Masse nicht unbedingt repräsentativ) und die gesammelte in der ML. Wegen Letzterer habe ich ja seit 10.3 auch eben ext3 (zumindest für die aktuellen Daten)

...

...

...

...

-dnh, nur noch mit ext2/ext3 (noch nicht ext4) unterwegs, die haben

ich habe ext4 auf unseren Notebooks (mit OS 11.2) ... ab und zu sind da irgendwelche plasma-Dateien korrupt, aber ob das an ext4 liegt oder doch eher an KDE4.x?

KDE4. Oder kannst du die Dateien auch mit cat / dd nicht mehr auslesen (sofern du Leserechte hast, ggfs. setzen, bei Reiserfs (s.o.) ging das aber nicht, da hat sich das FS verheddert)

konnte ich sogar mit kwrite, kate o.a. problemlos lesen - nur die Werte darin waren nicht so ganz passend. Könnte tatsächlich von KDE4 kommen (scheint auch seit dem Update auf 4.3.5 seltener geworden zu sein), könnte aber auch auf dem gerüchteweisen Problem beruhen, dass u.U. ext4 beim Absturz die letzten Schreibzugriffe "vergisst" - und damit bestimmte Werte in den Dateien nicht mehr ganz zusammen passen.

...

...

...

Sektoren liegenden Dateien betroffen (der Superblock wird zum
Glück und aus gutem Grund bei ext2/3 mehrfach redundant an
verschiedenen Stellen der Partition gespeichert -- das hat mir
mehr als einmal das FS gerettet!).

ist das bei ext4 nicht mehr so?

AFAIK schon, aber ich hab ext4 halt noch nicht angeschaut ;)

also zusammenfassend: reiserfs: nicht unperformant (speziell sehr gut bei vielen kleinen Dateien), aber Berichte über Fehlverhalten mit Datenverlust und faktisch fehlende Weiterentwicklung bzw. Korrekturen

ext2/ext3: ausgereift und stabil auch bei Hardwareausfällen, Performance in den meisten Fällen nicht schlecht (aber etwas lahm bei Verzeichnissen mit extrem vielen Dateien)

ext4: Performance wohl etwas besser als bei ext3, noch nicht so ausgetestet, in der Theorie vermutlich ähnlich stabil wie ext3

der Rest: kann ggf. sein bei besonders großen Dateien oder anderen Spezialfällen, wird aber zumindest unter OS nicht so gut getestet (bzw. so oft verwendet...) wie ext3 / ext4 - also eher für Leute, die ganz genau wissen, was sie damit tun ;-)

Hi Liste,

und was ist mit BTRFS ? Soll ja DAS FS der Zukunft sein. Ist das eigentlich auch clusterfähig ?

On 08.09.2010, Christian Brabandt wrote:

noch lange nicht ausgereift.

Naja, gut moeglich, dennoch waren bereits vor einigen Wochen einige Stimmen auf der lkml laut, dass btrfs nicht mehr unter "experimental" liegt :-)