Das ist ein Designfehler in ext4. Daran ändert jetzt auch die "Anklage" der Anwendungen nichts. Man hätte - aus dem Wissen der Arbeitsweise von ext3 heraus - damit rechnen müssen, dass diese Datenverluste passieren werden. Auch wusste der ext4-"Designer" sehr wahrscheinlich, wie die Anwendungen zur Zeit arbeiten. Trotzdem lässt man die Nutzer ohne jede Vorwarnung in die Falle laufen. Zur Zeit kann man nur sagen: Finger weg von ext4.
Wenn man die Diskussion in zahlreichen Anwenderforen verfolgt, dann ist das Bild eindeutig. Ext4 gilt als fehlerhaft und "wird erst eingesetzt, wenn der Fehler behoben ist", es sich also wie ext3 verhält. Damit wird das eigentliche Problem natürlich auch nur kaschiert.
Ich finde es schade, dass ext4 nun überhaupt zurechtgebogen wird, tatsächlich wäre dies eine Gelegenheit gewesen, mal richtig aufzuräumen und die Anwendungen zu patchen, zu allererst wohl Gnomes gconf und KDE. Das Thema ist doch jetzt in aller Munde, anstatt aus dem Problembewusstsein einen sanften Druck in Richtung Problembeseitigung aufzubauen, geht man nun opportunistisch den Weg des geringsten Widerstands und deckt das Problem zu, statt 60 Sekunden also wieder nur 10 Sekunden höchste Gefahr. Sehr schade, aber der Akzeptanz von ext4 sicher zuträglich. Verrückte Welt.
P.S. Werden andere Dateisysteme wie xfs jetzt auch den kaputten Anwendungen passend gepatcht?
Mit welchen Folgen kann man bei einem Stromausfall für verschlüsselte Container rechnen oder gibt es hier ein anderes Schreibverhalten? Ist der ganze Container samt Inhalt hinüber?
Wie ist das denn bei Datenbanken (hier z.B. MySQL)? Kann es unter EXT4 dann auch passieren, dass die Datei(!)-länge nach Ausfall des Servers auf 0 gesetzt wird?
Die Schuld liegt hier bei Qt, denn KDE benutzt exzessiv QSettings. Die Lösung des Problems ist also recht einfach, man muss nur QSettings dazu bekommen nach jedem Schreibvorgang fsync aufzurufen. Gleichzeitig könnte man QSettings so erweitern, dass die aktuelle Config-Datei immer im Speicher gehalten wird und wirklich nur bei Veränderungen zurückgeschrieben wird.
Insgesamt eine recht einfache Anpassung, die vielleicht etwas Speicher kostet. KDE muss übrigens nicht neukompiliert werden, nur die Qt-Libs.
In der realen Welt machen 99.x % der Anwendungen das geforderte fsync NICHT !!! Es ist ja auch die Aufgabe des Dateisystems, die Daten sicher auf die Platte zu befördern ... Wenn beim write() also nie ein Fehler aufgetreten ist.
Man kann eine solche Option evtl. auf einem Notebook mit Akku oder einem System mit USV gelten lassen, wenn sichergestellt ist, dass bei einer Alarmsituation (Battery low) der Cache auch sicher auf die Platte befördert wird.
Auf allen anderen Systemen gehört diese Option deaktiviert !!!
Na ja, es ist vielleicht in bisschen pech, wenn der strom ausfällt. Da wäre es in der tat schön, wenn der alte zustand auf der platte stünde. Aber für die anderen fälle, hardlock vom x-server gibts den "magic sysrq". Das passiert leider mit dem intel treiber zur zeit häufig, aber sowas hab ich bisher nicht erlebt mit ext4.
Mensch, endlich konnte mal jemand erklären, warum Firefox immer Denkpausen einlegen muß. Klikt mal auf den Link! Ist sehr interessant. Fragt man in irgendwelchen Foren oder hier um Rat, wird natürlich abgestritten, daß es Probleme gibt. Alle sind so super-überzeugt und sagen nur, ich könne ja gerne was anderes nehmen. Offensichtlich sind die meisten Leute unter Linux an ein hakeliges System so sehr gewöhnt, daß sie es gar nicht mehr wahrnehmen.
Von Michael Lehmeier am Mo, 16. März 2009 um 16:56 #
Ich weiß jetzt nicht, wieso KDE anscheinend diese Probleme hat, mit Abstürzen umzugehen.
Aber auf jeden Fall ist KDE schuld. Wieso? Weil man *immer* mit einem Stromausfall und etwas ähnlichem rechnen muss. Ohne Ausnahme. Jedes Programm hat selbst dafür Sorge zu tragen, dass die Konsequenzen dann mimimal bleiben. Wieso? Weil kein Dateisystem, absolut gar keines, sicherstellen kann, dass alle geschriebenen Daten auch auf der Platte landen. Wieso? Spätestens auf den Festplattencache hat das Dateisystem keinen Einfluss.
Was unterscheidet also ext4 von bisherigen Dateisystemen? Nun, im Vergleich zu XFS, einem lange und gern benutztem Dateisystem: Gar nichts. Und dort hat sich noch niemand beschwert. Wieso jetzt auf einmal der Skandal? Keine Ahnung. Deshalb denke ich, das ist eine Scheindiskussion. Im Vergleich zu anderen wie ext2? Der Unterschied ist nur, dass das Zeitfenster, in dem solche Unfälle passieren können, ein wenig größer ist. Das ist alles. Auch unter ext2 kann sowas passieren. KDE schützt einem davor genauso wenig.
Ich jedenfalls hab in meinem Programmen schon immer einen sicheren Weg gefahren. Bei wichtigen Daten erst mal geschrieben, dann die alte Version löschen und die neue umbenennen. Ein Risiko ist so fast nicht vorhanden, weder bei ext2, ext4 oder xfs. Unabhängig von irgendwelchen fsyncs. Wieso die bei KDE sowas für ihre Konfigurationsdateien nicht auf die Reihe kriegen, ist mir ein absolutes Rätsel.
Ich jedenfalls hoffe inständig, dass die von xfs und ext4 nicht einknicken und die technischen Errungenschaft der letzen Jahre zugunsten eines Bedarfsfalles kastrieren, der überhaupt nicht in den Verantwortungsbereich eines Dateisystems fällt.
Ich bin etwas verwundet. Auf USB-Ebene habe ich mehrfach gesehen, das ein Fsync allein auf eine Datei noch nicht zu einen SCSI-Write10 auf USB-Ebene fuehrt. Sollte das fsync auf das Verzeichnis das wirklich triggern?
Dass ext4 sich im Rahmen der POSIX Spezifikation korrekt verhält, ist schön und gut. Die Spezifikation läßt auch bewußt Freiräume und definiert explixit NICHT, was im Falle eines Absturzes tatsächlich auf der Platte stehen muß (abgesehen von fsync() & Co). Gerade dadurch werden viele Performance-Optimierungen erst möglich. Mich überrascht nicht, dass für die Performance-Verbesserungen ein entsprechender Preis bei der Datensicherheit im Falle eines Ausfalls zu zahlen ist. Trotzdem verwende ich ext4 und bin damit bisher sehr zufrieden (und eine USV hab ich schon lange).
Meine einzige Kritik am Verhalten der Kernel-Entwickler in Bezug auf ext4 ist, dass dieses Dateisystem per default zu sehr auf Performance und zu wenig auf Sicherheit getrimmt ist. Ein Anwender, der sich nicht näher mit Filesystem-Parametern/Mount-Optionen beschäftigt, sollte meiner Meinung nach lieber ein in jedem Fall sicheres System haben als ein schnelles. Wer hohen Wert auf Performance legt, soll immer noch die Möglichkeit haben, sein System entsprechend zu tunen und evtl. höheres Risiko einzugehen. Wenn der dann deswegen Daten verliert, kann er wenigstens nur sich selbst die Schuld geben - nicht den Kernel-Entwicklern und auch nicht den Anwendungsprogrammieren.
Das Problem ist nicht, daß man nach dem crash alte Daten hat. Das Problem ist, daß man nach einem crash KEINE Daten hat. Daten, die schon auf der Platte waren werden zerstört. Was früher mit ext2&3 in Ordnung war, klappt nicht mehr. Und dann sollen Anwendungen Schuld sein? Wenn /etc/passwd plötzlich 0byte groß ist, dann hat man ein Problem! Wenn sich plötzlich das Verhalten ändert, dann ist das einfach scheiße!
Und komischerweise gibt es Dateisysteme, die dieses Problem nicht haben. Reiserfs und Reiser4. Vielleicht hätte man sich die mal ansehen sollen? Aber ach, 'not invented here' ist ein ausgeprägtes Syndrom bei ext-Entwicklern und Redhat-Mitarbeitern. Wenn diese dann auch noch in einer Gruppe vereint sind, ist Lernresistenz das Ergebnis.
Ted sollte den Mut haben und zugeben, daß ext4 gescheitert ist. Ein Fehldesign. Markiert den Schrott als BROKEN und laßt es gut sein. btrfs ist bald fertig, solange wird ext3 noch reichen. Aber schon finster, daß ein 'stable' FS Daten VERNICHTET, aber ein FS das entwickelt wurde, damit so ein Fall niemals eintreten kann, darf nicht in den Kernel. Wirft ein ziemlich schlechtes Licht auf die Meute.
Ein ähnliches Problem tritt uebrigens mit SATA-Devices auf: Nach einem Resett/Stromausfall, kann es durchaus vorkommen, das trotz fsync (zb bei postgres explizit aktiviert) die DB geschrottet ist. Die Erfahrungen habe ich mit Kernel 2.6.24 gemacht.
Imho ist dort die einzige Moeglichkeit das zu umgehen ein explizites deaktivieren des Device-Internen Caches: hdparm -W 0 /dev/xxx - oder halt eine USV...
A hat schuld B hat schuld. Das ist doch egal. Wichtig ist doch nur, dass sich das Dateisystem (und auch POSIX) in dem Fall unerwartet verhält. Ich kann verstehen, dass man aus gründen der Optimierung nicht alles sofort auf die Platte schreiben will (wobei ich 60sek doch für recht lang halte...) Aber was ich nicht verstehe ist, dass auf der Disk unter Umständen die Dateiattribute vor dem Inhalt geändert werden, obwohl die Befehlsreihenfolge von der Applikation anders ist. Es währe schön wenn mir das jemand verständlich macht. In den POSIX-Spezifikationen habe ich darüber nichts gefunden. (wahrschinlich nicht richtig gesucht...) Sicherlich ein Dateiattribut ändern ist in den meisten fällen nicht schlimm, beim umbenennen und löschen einer Datei aber schon. Ich persönlich würde erwarten, dass sie von mir vorgelegte Reihenfolge der Befehle eingehalten wird.
Jetzt mal als Laie: Das ist doch ein Designfehler, oder? Als Normalsterblicher will ich, dass, wenn ich auf das Diskettenicon klicke, die Datei auf der Platte ist. Und zwar sofort. Dafür gibt es doch Betriebs- und Dateisysteme, die sich darum kümmern, dass nicht jeder Texteditor, jede Bildbearbeitung usw. das alles noch selbst handeln muss, oder?
Von Please_listen_Teddy am Di, 17. März 2009 um 10:13 #
... ist vielleicht, dass eine Provokation an die Community zwar leicht auszulösen, aber nicht immer sinnvoll und schon gar nicht vertrauenssichernd ist. Ich kann mir nicht vorstellen, dass Ted Ts'o ein unsicheres FS entwickeln wird - ext4 wird sicher ein performantes und stabiles FS, es wurde vielleicht ein wenig früh als "stabil" geflagged. Ich denke, es wäre in einem so sensiblen Bereich wie Dateisysteme einfach die bessere Publicity gewesen, sich artig bei der Community für den Test und das Finden dieses grundlegenden und schwer wiegenden Problems in den FS's der "nächsten Generation" zu bedanken und baldige Lösung zu versprechen, statt irgendwelche Schuld bei irgendwem zu suchen und bei dieser Gelegenheit gleich noch Anforderungen an ggw und künftige Applikationen und Betriebssysteme zu formulieren. Ich denke, das ist es, was ext4 aus dieser heißen Diskussion lernen kann. Denn in der Tat haben Anwender und Entwickler einen Anspruch darauf, dass sie darauf vertrauen dürfen, dass ein FS die Daten sicher auf die HD (oder sonstwas) schreibt und auch dort lässt, wenn man nichts bewusst daran ändert. Diese ganze Diskussion hat mehr Misstrauen in ext4 geschürt als notwendig. Ich hoffe, sie wird von den ext4-Machern wahrgenommen und sorgt dafür, dass sie die Bedenken ernst nehmen und in Kernel 2.6.30 ein hervorragendes FS vorlegen, das die Probleme nicht nur patcht, sondern löst.
Wenn ich ein Journaling File System einsetze, gehe ich davon aus, das Änderungen an Daten transaktional durchgeführt werden. Wenn eine Schreiboperation scheitert, erwarte ich vom Filesystem ein Rollback der Aktion beim Reboot. Eine defekte leere Datei ist keine akzeptable Option.
Werde wohl meine Server zurück zu Windows migrieren.
Ein konfigurierbares write-trough sollte man mindestens anbieten, um den cache beim Schreiben abschalten zu können - das ist standard bei jedem besseren Controller, der hardwareseitig cached - für ein Filesystem sollte das selbstverständlich sein.
Daran ändert jetzt auch die "Anklage" der Anwendungen nichts.
Man hätte - aus dem Wissen der Arbeitsweise von ext3 heraus - damit rechnen müssen, dass diese Datenverluste passieren werden.
Auch wusste der ext4-"Designer" sehr wahrscheinlich, wie die Anwendungen zur Zeit arbeiten.
Trotzdem lässt man die Nutzer ohne jede Vorwarnung in die Falle laufen.
Zur Zeit kann man nur sagen: Finger weg von ext4.
Ich finde es schade, dass ext4 nun überhaupt zurechtgebogen wird, tatsächlich wäre dies eine Gelegenheit gewesen, mal richtig aufzuräumen und die Anwendungen zu patchen, zu allererst wohl Gnomes gconf und KDE. Das Thema ist doch jetzt in aller Munde, anstatt aus dem Problembewusstsein einen sanften Druck in Richtung Problembeseitigung aufzubauen, geht man nun opportunistisch den Weg des geringsten Widerstands und deckt das Problem zu, statt 60 Sekunden also wieder nur 10 Sekunden höchste Gefahr. Sehr schade, aber der Akzeptanz von ext4 sicher zuträglich. Verrückte Welt.
P.S. Werden andere Dateisysteme wie xfs jetzt auch den kaputten Anwendungen passend gepatcht?
alter Inhalt kann ich akzeptieren aber leer nicht!
Bei Datenbanken gibt es doch auch:
BEGIN;
.....
COMMIT;
bzw.
ROLLBACK;
Warum nicht beim Filesystem!
wie kann ich unter linux herauskriegen welche grafikkarte in meinem notebook steckt?
( ich weiß, es ist OT)
mfg
habe dieses Problem selbst erlebt!
Distribution Mandriva, Filesystem Ext4 - nach einem ungewollten Shutdown waren alle URPM-Repositoryfiles 0kb groß.
Ich bin und bleibe XFS treu, da habe ich sowas in vielen Jahren noch nie erlebt.
Lauter dämliche Frage, aber danke für eure Zeit.
Insgesamt eine recht einfache Anpassung, die vielleicht etwas Speicher kostet. KDE muss übrigens nicht neukompiliert werden, nur die Qt-Libs.
Es ist ja auch die Aufgabe des Dateisystems, die Daten sicher auf die Platte zu befördern ...
Wenn beim write() also nie ein Fehler aufgetreten ist.
Man kann eine solche Option evtl. auf einem Notebook mit Akku oder einem System mit USV gelten lassen,
wenn sichergestellt ist, dass bei einer Alarmsituation (Battery low) der Cache auch sicher auf die Platte befördert wird.
Auf allen anderen Systemen gehört diese Option deaktiviert !!!
Aber auf jeden Fall ist KDE schuld.
Wieso?
Weil man *immer* mit einem Stromausfall und etwas ähnlichem rechnen muss. Ohne Ausnahme. Jedes Programm hat selbst dafür Sorge zu tragen, dass die Konsequenzen dann mimimal bleiben.
Wieso? Weil kein Dateisystem, absolut gar keines, sicherstellen kann, dass alle geschriebenen Daten auch auf der Platte landen. Wieso? Spätestens auf den Festplattencache hat das Dateisystem keinen Einfluss.
Was unterscheidet also ext4 von bisherigen Dateisystemen?
Nun, im Vergleich zu XFS, einem lange und gern benutztem Dateisystem: Gar nichts. Und dort hat sich noch niemand beschwert. Wieso jetzt auf einmal der Skandal? Keine Ahnung. Deshalb denke ich, das ist eine Scheindiskussion.
Im Vergleich zu anderen wie ext2? Der Unterschied ist nur, dass das Zeitfenster, in dem solche Unfälle passieren können, ein wenig größer ist. Das ist alles. Auch unter ext2 kann sowas passieren. KDE schützt einem davor genauso wenig.
Ich jedenfalls hab in meinem Programmen schon immer einen sicheren Weg gefahren. Bei wichtigen Daten erst mal geschrieben, dann die alte Version löschen und die neue umbenennen.
Ein Risiko ist so fast nicht vorhanden, weder bei ext2, ext4 oder xfs. Unabhängig von irgendwelchen fsyncs. Wieso die bei KDE sowas für ihre Konfigurationsdateien nicht auf die Reihe kriegen, ist mir ein absolutes Rätsel.
Ich jedenfalls hoffe inständig, dass die von xfs und ext4 nicht einknicken und die technischen Errungenschaft der letzen Jahre zugunsten eines Bedarfsfalles kastrieren, der überhaupt nicht in den Verantwortungsbereich eines Dateisystems fällt.
Hier meldet sich bei mir Zweifel und Staunen an.
Meine einzige Kritik am Verhalten der Kernel-Entwickler in Bezug auf ext4 ist, dass dieses Dateisystem per default zu sehr auf Performance und zu wenig auf Sicherheit getrimmt ist. Ein Anwender, der sich nicht näher mit Filesystem-Parametern/Mount-Optionen beschäftigt, sollte meiner Meinung nach lieber ein in jedem Fall sicheres System haben als ein schnelles. Wer hohen Wert auf Performance legt, soll immer noch die Möglichkeit haben, sein System entsprechend zu tunen und evtl. höheres Risiko einzugehen. Wenn der dann deswegen Daten verliert, kann er wenigstens nur sich selbst die Schuld geben - nicht den Kernel-Entwicklern und auch nicht den Anwendungsprogrammieren.
Lest bitte den Text unter dem oben angegebenen Launchpad-Link.
Das Problem ist nicht, daß man nach dem crash alte Daten hat. Das Problem ist, daß man nach einem crash KEINE Daten hat. Daten, die schon auf der Platte waren werden zerstört. Was früher mit ext2&3 in Ordnung war, klappt nicht mehr. Und dann sollen Anwendungen Schuld sein? Wenn /etc/passwd plötzlich 0byte groß ist, dann hat man ein Problem! Wenn sich plötzlich das Verhalten ändert, dann ist das einfach scheiße!
Und komischerweise gibt es Dateisysteme, die dieses Problem nicht haben. Reiserfs und Reiser4. Vielleicht hätte man sich die mal ansehen sollen? Aber ach, 'not invented here' ist ein ausgeprägtes Syndrom bei ext-Entwicklern und Redhat-Mitarbeitern. Wenn diese dann auch noch in einer Gruppe vereint sind, ist Lernresistenz das Ergebnis.
Ted sollte den Mut haben und zugeben, daß ext4 gescheitert ist. Ein Fehldesign. Markiert den Schrott als BROKEN und laßt es gut sein. btrfs ist bald fertig, solange wird ext3 noch reichen.
Aber schon finster, daß ein 'stable' FS Daten VERNICHTET, aber ein FS das entwickelt wurde, damit so ein Fall niemals eintreten kann, darf nicht in den Kernel. Wirft ein ziemlich schlechtes Licht auf die Meute.
Nach einem Resett/Stromausfall, kann es durchaus vorkommen, das trotz fsync (zb bei postgres explizit aktiviert) die DB geschrottet ist. Die Erfahrungen habe ich mit Kernel 2.6.24 gemacht.
Imho ist dort die einzige Moeglichkeit das zu umgehen ein explizites deaktivieren des Device-Internen Caches: hdparm -W 0 /dev/xxx - oder halt eine USV...
Gruss,
Andre
Wichtig ist doch nur, dass sich das Dateisystem (und auch POSIX) in dem Fall unerwartet verhält.
Ich kann verstehen, dass man aus gründen der Optimierung nicht alles sofort auf die Platte schreiben will (wobei ich 60sek doch für recht lang halte...) Aber was ich nicht verstehe ist, dass auf der Disk unter Umständen die Dateiattribute vor dem Inhalt geändert werden, obwohl die Befehlsreihenfolge von der Applikation anders ist.
Es währe schön wenn mir das jemand verständlich macht. In den POSIX-Spezifikationen habe ich darüber nichts gefunden. (wahrschinlich nicht richtig gesucht...)
Sicherlich ein Dateiattribut ändern ist in den meisten fällen nicht schlimm, beim umbenennen und löschen einer Datei aber schon.
Ich persönlich würde erwarten, dass sie von mir vorgelegte Reihenfolge der Befehle eingehalten wird.
Diese ganze Diskussion hat mehr Misstrauen in ext4 geschürt als notwendig. Ich hoffe, sie wird von den ext4-Machern wahrgenommen und sorgt dafür, dass sie die Bedenken ernst nehmen und in Kernel 2.6.30 ein hervorragendes FS vorlegen, das die Probleme nicht nur patcht, sondern löst.
Werde wohl meine Server zurück zu Windows migrieren.
Ein konfigurierbares write-trough sollte man mindestens anbieten, um den cache beim Schreiben abschalten zu können - das ist standard bei jedem besseren Controller, der hardwareseitig cached - für ein Filesystem sollte das selbstverständlich sein.