OVH Community, your new community space.

ext3 -> ext4


pendulum
13.04.09, 23:40
Ja das stimmt, bei ext3 is das alte Zeug noch da. Is also nur ein halbes Problem. Dennoch sollten die Softwareentwickler, die sowas nicht beachten ne kleine Ohrfeige bekommen
Und klar, für den Produktiveinsatz würd ich auch niemals jetz schon ext4 einsetzen, das wäre verantwortungslos.
Aber für unwichtige Daten, warum nicht

Mit dem Zeitfenster meinte ich den Zeitraum zwischen dem "schreib das mal" und dem "jetz ises wirklich auf der Platte". Das wurde erheblich vergrößert.

strex
13.04.09, 23:20
Bei ext4 ändert sich nicht die Zeit sondern es wird ein neuer Status eingefürt. Bei diesem Status "delayed block allocation" kann das System die Prozess nach Leistung ordnen und ausführen. Wenn sich aber eine Änderung in diesem Status befindet und das System stürtzt ab, dann war bei ext3 noch die alte Datei verfügbar. Bei ext4 ist es nun so, dass es keine Datei mehr gibt, weder alte noch neue und somit ein kompletter Datenverlust droht. Das ist zwar nach POSIX korrekt , jedoch sind viele Programme nicht exakt genug und somit unsicher.

Es gibt zwar einen Patch der ext4 das Verhalten zu ext3 abändert, aber trotzdem bleibt mir ext4 noch zu wenig getestet. Das lasse ich lieber erstmal andere als Tester ran. Zumal ja die Vorteile nicht wirklich überwiegen und es kaum zu einer Vebesserung der Leistung beiträgt.

pendulum
13.04.09, 22:51
Das Dateisystem funktioniert auch ordnungsgemäß wenn man es ordnungsgemäß benutzt.
Neue Datei schreiben => fsync() => rename(old, new). Dann geht auch nix verlohren.
Wenn man es nicht so macht, dann kann einem auch bei ext3 und anderen Dateisystemen Datenverlust blühen. Nur bei ext4 ist das Zeitfenster, in dem es passieren kann größer und is deswegen aufgefallen.

Vorteile bringt ext4 natürlich schon. Unter anderem endlich das lang ersehnte online defrag und schnellere fscks.

strex
13.04.09, 20:31
Zitat Zitat von pendulum
Der von dir geschilderte Fall, strex, tritt aber nur auf weil soviele Programme fehlerhaft programmiert wurden, was das Speichern von Dateien angeht
Is nich wirklich ext4s Schuld.
Nett Bug ist es trotzdem, gut beschrieben in der aktuellen c´t. Doch ist ein Bug mit der Abhängigkeit zu verschiedene Funktionen die durch Programme genutzt werden. Da es erst im kommenden Kernel gefixt wird, sollte man es nicht einsetzen. Vorteile ringt ext4 ja nicht, warum nicht dann das stabile ext3 nutzen?

So ist das Dateisystem, was ja eine sehr wichtige Funktion hat, nicht wirklich brauchbar. Ein Dateisystem muss einfach ordnungsgemäß laufen.

kro
13.04.09, 20:30
thorwin wrote:
> nicht erkannt werden. Offensichtlich ist die Version von tune2fs noch
> nicht ext4-aware. Ist da Änderung im Plan? Folgender Befehl wurde
> verwendet:


Solange in unserem rescue-system noch kein ext4-kompatible tools sind rate ich
*dringendst* von der Benutzung von (nicht abwärtskompatiblem) ext4 ab.
Insbesondere auf dem RPS. Wie du einige Features von ext4 nutzen kannst ohne
das on-disk-format zu beeinflussen erfährst du hier:
http://kernelnewbies.org/Ext4#head-1...83a86c8cf4b6a6
--
Felix
OVH Team

thorwin
13.04.09, 20:21
Zitat Zitat von pendulum
Is nich wirklich ext4s Schuld.
Ich erinnere mich mit Grauen an meine Experimente mit reiser4 vor einiger Zeit (~ 1 1/2 Jahre oder so) zurück. Da gab es den Fall, dass das Dateisystem nach einem "harten" Absturz 100% konsistent war, aber leider leer...
Und im Ernst: Lieber eine alte und eine neue Datei weg, als einen undefinierten Zwischenzustand, wie er bei z.B. reiser auftreten kann.

pendulum
13.04.09, 20:18
Der von dir geschilderte Fall, strex, tritt aber nur auf weil soviele Programme fehlerhaft programmiert wurden, was das Speichern von Dateien angeht
Is nich wirklich ext4s Schuld.

thorwin
13.04.09, 20:17
Zitat Zitat von strex
Derzeit würde ich von ext4 abstand nehmen, da gibt es noch nette Probleme, wenn die es bei der Änderung einer Datei zu einem Absturz kommt. Dann ist weder die alte noch die neue Datei vorhanden. Wirklich Vorteile bringt ext4 eh noch nicht, ein Dateisystem muss sich erst einmal bewähren bevor ich es einsetzen würde. Bei sowas lieber immer eine Version dahinter bleiben.
Naja, ich hab noch keine Probleme mit ext4 gehabt bisher (ganz im Gegensatz zu reiser4 früher... ) und es lief/läuft schon auf ner ganzen Menge Installationen. Auch die Migration ext3 -> ext4 ist mir nicht neu, es sind ja lediglich die zu alten e2fsprogs im Rescue-System.

strex
13.04.09, 17:54
Derzeit würde ich von ext4 abstand nehmen, da gibt es noch nette Probleme, wenn die es bei der Änderung einer Datei zu einem Absturz kommt. Dann ist weder die alte noch die neue Datei vorhanden. Wirklich Vorteile bringt ext4 eh noch nicht, ein Dateisystem muss sich erst einmal bewähren bevor ich es einsetzen würde. Bei sowas lieber immer eine Version dahinter bleiben.

thorwin
13.04.09, 17:40
Hallo,

ich würde gerne meinen RPS-2 von ext3 nach ext4 migrieren. Allerdings bekomme ich im rescue-System den Fehler, dass die Optionen von tune2fs nicht erkannt werden. Offensichtlich ist die Version von tune2fs noch nicht ext4-aware. Ist da Änderung im Plan? Folgender Befehl wurde verwendet:
Code:
# tune2fs -O extents,uninit_bg,dir_index /dev/sdaX
Danke und Gruß, thorwin