Möglicher Niveau-Verlust bei Heise

Heise hatte gestern abend eine heiße Schlagzeile:

Möglicher Datenverlust bei Ext4

Und wie es sich für so eine Bild-Schlagzeile gehört mit einem großen orangenen Warndreieck daneben.

Kurze Hintergrund-Information: Die nächste Ubuntu-Version kommt mit dem neuen Linux-Dateisystem "ext4". Nun wurde festgestellt, dass bei einem Absturz kurz nach dem Start die Konfigurationsdateien von KDE und Gnome zerstört (= geleert) sein können, was einen erneuten Start etwas schwierig macht. Nach einer kurzen Analyse hat der Entwickler des Dateisystems, Ted Ts'o, einen Workaround geschrieben, aber auch deutlich gemacht, dass eigentlich die Anwendung fehlerhaft programmiert ist.

Und im Heise-Forum ging die Flamerei los!

Erst nach sechs Stunden hat sich mal jemand die Mühe gemacht, den Original-Kommentar von Ted Ts'o zu lesen. Kurz zusammengefasst: Viele Programmierer verlassen sich darauf, dass nach einem close() die Dateien auf der Festplatte liegen - was aber per Definition nicht wahr ist, erst ein flush() stellt dies sicher. Und damit ist es definitiv ein Fehler in der Anwendung, der halt erst dann auffällt, wenn das Dateisystem - wie auch ext4 - die Daten aus Performanz-Gründen lange im Speicher behält.

Aber das wirklich hässliche am Heise-Forum ist: All diese unqualifizierten Beiträge sind grün bewertet worden.

Nachtrag: Eine kurze und gute Erklärung des Problems auf deutsch gibt es inzwischen auch.

Nachtrag 2:

Ablauf einer Dateioperation:

open("w")
Achtung Betriebssystem, ich möchte in diese Datei schreiben, lass bloß niemand anderen da jetzt dran!
close()
So, ich bin fertig, nun dürfen andere auch wieder.
flush()
Hey Betriebssystem, ich hoffe, DU bist auch fertig mit der Datei.

Comments

Zu Nachtrag 2:

Das ist ein bisschen abhängig von der Programmiersprache/Bibliothek:

open(”w”)
Achtung Betriebssystem, ich möchte in diese Datei schreiben, lass bloß niemand anderen da jetzt dran!
flush()
Hey Betriebssystem, schreib mal bitte alles Physikalisch auf das Speichermedium
close()
So, ich bin fertig, nun dürfen andere auch wieder.

Sollte immer funktionieren.

Die Reihenfolge close(), flush() sorgt z.B. bei Python für einen Fehler, weil close() implizit für ein flush() sorgt und auf einmal geschlossenen Dateien keine IO Operationen mehr erlaubt sind ... bei c/c++ mag das anders sein, bin ich mir gerade nicht sicher.

Was die Reihenfolge angeht hast du recht, aber es ging mir auch nur um die Bedeutung der Aufrufe. Dazu dass close() in Python ein flush() impliziert kann ich nichts finden, zumindest die Doku erwähnt dieses Verhalten nicht. Hast du da ne Quelle?

Ja, das hat mich gestern auch ein wenig aufgeregt. :) Musste so das ein oder andere mal denken: "Wenn man keine Ahnung hat, einfach mal ..." :)

Allerdings kann ich auch nachvollziehen, dass es für den Laien vielleicht schwer begreiflich ist, dass man einen Mittelweg zwischen Performance und Sicherheit finden muss. Der geht halt davon aus, dass Daten, die gespeichert sind, eben auch auf Platte liegen.

Ich denke es ist wie Ted sagt, man muss da mit den Anwendungsentwicklern Hand in Hand arbeiten und sie dafür sensibilisieren, was sie wirklich wollen: schnelles oder sicheres Speichern.

Außerdem sollte man da vielleicht auch über die Praxis mit dem neu erstellen und dann verschieben nachdenken.

Ich kenn mich ja mit Dateisystemen gar nicht aus, aber Nachtrag 2 finde ich außerordentlich gut ^^. In diesem Sinne: close().

Ja das stimmt wohl, die Doku erwähnt es wirklich nicht, hab aber grad mal Tante Google gefragt und Guido van Rossum sagt auf der ML selbst, dass ein flush implizit ist.

Add new comment