Bei heise kann man es genauer nachlesen: Möglicher Datenverlust bei Ext4
Ext3 und Ext4 verwenden
![]() Anmeldungsdatum: Beiträge: 7943 |
|
![]() Anmeldungsdatum: Beiträge: 883 Wohnort: Dortmund |
Vegeta schrieb:
Danke für den Link Wie dieser Kommentator es beschreibt so sehe ich das auch alles andere ist imho sehr unelegant |
Anmeldungsdatum: Beiträge: 870 |
Versteh ich nicht. Der Programmierer weiß doch am besten, wann er asynchron oder synchron schreiben möchte. Was soll nun das Problem sein, das auch entsprechend umzusetzen? Schließlich taucht das "Problem" doch bei allen FS auf, die Daten nicht automatisch sofort schreiben. |
![]() Anmeldungsdatum: Beiträge: 294 Wohnort: berlin |
Ich verstehe das Ganze immer noch nicht so ganz: Natürlich sind noch nicht geschriebene Daten im Falle eines Crashes futsch, aber warum werden die alten (zu überschreibenden) Daten auch gleich mitvernichtet, obwohl die Festplatte ja noch gar nicht angefasst wurde? Wieso ist das kein Bug? Nur weil POSIX in diesem Bereich bewusst schwammig ist? |
Anmeldungsdatum: Beiträge: Zähle... |
@ Dawnrazor Das Problem ist, dass alle, die die Schuld hier allein aufs Dateisystem schieben, den Sinn und Zweck von Delayed Allocation nicht verstanden haben. Es geht dabei nur sekundär darum, der Allozierung der Blöcke oder Extents mehr Zeit zu geben um Fragmentierung zu vermeiden - primär geht es darum, dass die haufenweise temporären Dateien, die die gleichen Anwendungsautoren erzeugen lassen, die hier die Schuld von sich weg schieben, gar nicht auf die Disk geschrieben werden, solange im RAM genug Platz ist. Das ist sinnvoll, weil die tenmporären Dateien ja eh kurzfristig wieder gelöscht werden und bei Systemcrashes auch verzichtbar sind. Ohne Delayed Allocation müllen diese temporären Dateien das Dateisystem zu. Dass fsync mehr Performance koste, als Delayed Allocation zu deaktivieren, ist deshalb unter dem Strich nicht ganz richtig, weil bei diesem Vorurteil ausgeblendet wird, dass Delayed Allocation eben immernoch verhindert, dass die tatsächliche Disk mit Temporärdateien zugemüllt wird. |
![]() Anmeldungsdatum: Beiträge: Zähle... |
Was temporäre Dateien und Logs anginge, könnte das Dateisystem diese ja anders behandeln, oder? Zumindest denke ich, dass der Grundgedanke, der momentan verfolgt wird, generell der falsche Ansatz ist. Es ist ja die Rede von bis zu 120 Sekunden Delay, das ist meiner Meinung nach deutlich zu viel und nur ein unnötiges Risiko. |
Ehemalige
![]() Anmeldungsdatum: Beiträge: 9144 Wohnort: NRW |
|
Anmeldungsdatum: Beiträge: 870 |
primus pilus schrieb:
Egal wie groß nun das Zeitfenster ist, das Risiko geht jeder Anwendungsprogrammierer bewußt ein - heute vielleicht bewußter als früher, also hat das ganze vielleicht doch auch einen positiven Effekt. |
Anmeldungsdatum: Beiträge: 4 |
mendres schrieb:
Dafür ist im POSIX-Standard ja eben eigentlich fsync vorgesehen, benutzt nur niemand, weil fsync angeblich mehr macht und deshalb mehr Zeit kostet, als nur eine gepufferte Datei von dem Puffer auf den Festspeicher zu befehlen. Wenn ich in einem Unix dh. in einem POSIX-System, und bis auf die fehlende ksh umfasst das eben auch Linux-Systeme, sicherstellen will, dass die Datei auch wirklich geschrieben wird, muss ich, das ist nunmal in POSIX so definiert, fsync dafür benutzen. Vielleicht lernen die ganzen "GNU is not Unix"-Gebetsmühlen jetzt, dass Arnold Willemer recht hatte, als er 2002 in "Wie werde ich UNIX-Guru" schrieb: "Inzwischen besteht kein ernsthafter Zweifel mehr, dass Linux ein >>echtes<< UNIX ist." Ich benutze seit fünf Jahren XFS und habe nicht das geringste Problem damit, dass meine Delayed Allocation auf meinen Systempartitionen gar kein Limit hat. Wie in der ellenlangen Dikussion der FS-Entwickler ja auch mehrmals deutlich gemacht worden ist: Deine Festplatte hat einen Cache und wenn du Pech hast sind selbst die zu schreiben befohlenen Dateien noch im flüchtigen HDD-Cache, wenn der Strom ausfällt. Genrerell finde ich die ganze Panik der Ext-Userschaft auch etwas merkwürdig, weil jeder erfahrene Linux-User, der es in eine solche Diskussion schafft, weiß, was Mount-Optionen sind. Ext4 habe ich selbst noch nicht probiert, aber XFS kann ich, wenn ich will, auch ohne Delayed Allocation mounten - ich kann mir nicht vorstellen, dass das bei Ext4 nicht ginge. 😉 Wenn die Kernel-Entwickler jetzt meinen, die Entcheidung darüber, was im Puffer bleibt und was festgeschrieben werden soll, würde ins Dateisystem und nicht wie von POSIX vorgesehen in die Anwendung gehören, dann möchte ich mal wissen warum die gleichen Herren Reiser4 abgelehnt haben, nur weil es sich nicht 100% an POSIX-Vorgaben hielt. |
Ehemalige
![]() Anmeldungsdatum: Beiträge: 9144 Wohnort: NRW |
MountWalker schrieb:
Mit dem Unterschied das dann wenigstens noch die alte Version der Daten vorhanden ist.
Die Option heißt alloc_on_commit zur Zeit ist sie aber noch nicht implementiert. Kommt wohl mit 2.6.30. Ich halte die Panik allerdings auch für übertrieben. |
Anmeldungsdatum: Beiträge: 4 |
Die alte Version der Daten geht ja nur verloren, wenn entweder die Metadaten schon entgültig geschrieben sind, bevor der Dateiinhalt geschrieben ist - was laut Analysis of SGI XFS File System (PDF) nichtmal bei XFS so ist - oder der Dateiinhalt bereits angefangen wurde zu überschreiben. Bei beidem unterscheidet sich der HDD-Cache in seiner Auswirkung nicht vom Dateisystemcache im RAM. Wenn der Fehler an Write-Back-Journaling statt Ordered-Journaling liegen sollte (also Metadatenjournal kann gelehrt werden, bevor Daten vollständig sind), hätte Delayed Allocation gar nichts mit dem Problem zu tun. |
Anmeldungsdatum: Beiträge: Zähle... |
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 ich habs gelesen, aber versteh nicht, was da jetzt gefixt wurde..?! |