Hallo liebe Gemeinde,

gestern ist mir etwas passiert, das mir noch nie vorgekommen ist:

Ich habe ca. eine halbe Stunde lang etwas in OpenOffice geschrieben, und, paranoid wie ich bin, immer wieder zwischengespeichert. Nachdem ich fertig war, habe ich OpenOffice geschlossen und anschließend ca. zehn Minuten lang im Internet recherchiert. Als ich den Laptop herunterfahren wollte, ist er während dem Shutdown hängen geblieben. Kein Problem, wir kennen ja Alt + Sysreq + REISUB. Alles schön langsam hintereinander eingegeben, Laptop bootet neu und ich rufe zur Sicherheit die zuletzt bearbeitete Datei in OpenOffice erneut auf. OpenOffice startet (ohne Wiederherstellungshinweis) und - die Datei ist auf dem Stand vor meiner Bearbeitung! Es ist so, als hätte ich an diesem Abend nie daran gearbeitet! Eine halbe Stunde Arbeit waren weg. Ürigens tauchten auch die nach OpenOffice angesurften Webseiten in der Firefox-Historie nicht auf.

Es ist mir zwar klar, dass die Festplatten u.U. aufgrund von Caching verzögert schreiben, aber dass eine halbe Stunde lang + zehn Minuten - trotz mehrfachem Speichern der Datei in OpenOffice - nichts auf die Festplatte geschrieben wurde, haut mich ehrlichgesagt vom Hocker.

Ein nach dieser Erkenntnis durchgeführtes fsck -fCv auf das /home-Verzeichnis bemerkt zwar ein inkonsistentes Journal und stellt es wieder her, aber meine Änderungen sind trotzdem weg.

Wie kann das sein?

PS: Ich verwende eine separate ext4 /home-Partition, die mit dm-crypt verschlüsselt ist. Diese Konstellation habe ich seit etlichen Jahren (gut, früher natürlich mit ext3) und hat noch nie Probleme bereitet. Falls es relevant ist, ich arbeitete an diesem Abend mit Kerberos im Offline-Modus (Cached Credentials).

Aber Datei.end~ gibts nicht oder?

Das Thema interessiert mich jetzt aber auch, denn dass Caching unter luks etwas stärker ist bzw. extrem war mir klar, aber deine Schilderung hört sich exorbitant an.

Hallo Das Wort,

seit langer, langer Zeit plane ich, dir zu antworten... bloß, ich bin bis heute nicht dazu gekommen (sorry). Aber dafür habe ich inzwischen einige Erfahrungen mit dem oben genannten Problem machen können.

Zuerst: Das Problem tritt ausschließlich dann auf, wenn ich per WLAN mit meinem Netzwerk verbunden bin. Dann ist es reproduzierbar. GPRS über Bluetooth/USB oder LAN funktionieren hingegen problemlos. WLAN über das Smartphone bringt interessanterweise denselben Fehler. Woran es genau liegt, habe ich bisher nicht heraus finden können. Es sind einfach zu viele Teile an dem ganzen Prozess beteiligt. Möglicherweise liegt es am nscd oder am Network Manager und einer ungünstigen Konstellation von verschiedenen Umständen bzw. Bestandteilen. Vielleicht sogar an einer falschen Konfiguration, wobei, wie gesagt, das Problem erst seit Maverick auftritt.

Wie dem auch sei, der Support für Maverick ist abgelaufen und das nächste LTS-Release steht vor der Tür. Ich werde früher oder später auf dem Desktop auf Precise Pangolin umsteigen und dann natürlich testen, ob das Problem weiterhin besteht. Eventuell werde ich im Zuge dessen auch auf nss-pam-ldapd, sssd oder nss-pam-ldapd in Kombination mit dem slapd nssov overlay umsteigen.

PS: Die Datei.end~ gibt es nicht, nein. Und es ist nicht auf OpenOffice-Dokumente beschränkt, sondern betrifft prinzipiell jede Datei, die in diesem Zeitraum geändert wurde. Aber auch nicht immer

Das ist mir als Nutzer von Ext3 auch schon aufgefallen. Dateien auf die während eines Absturzes (Sofortabschaltung durch Überhitzung oder teilweise auch Runterfahren mit REISUB) schreibend zugegriffen wurde, sind nach dem Hochfahren nicht mehr existent. Ich vermute, dass das Filesystem eine Inkonsistenz feststellt und dann den ganzen Eintrag löscht, obwohl es die Dateien eigentlich nach "lost&found" schieben müsste. Das ist entweder ein Bug oder man hat sich nicht richtig Mühe gemacht, solche Probleme aufzulösen. Richtig ist es aber nicht.

Gut, das liegt ja am Caching des Dateisystems und ist ja an- und für sich erstmal nicht ungewöhnlich (ich dachte allerdings immer, ein REISUB - vor allem das "S" in REISUB, was ja für "Emergency Sync" steht, wäre sicher und würde nicht zu Inkonsistenzen führen).

Ungewöhnlich ist allerdings die lange Caching-Dauer. Normalerweise werden Dateien so um die 60-90 Sekunden im Cache gehalten und danach geschrieben. Aber doch keine halbe Stunde!

Ich vermute mal, dass man REISUB nicht einfach blind hintereinander im Sekundenabstand eintippen sollte. Die Buchstaben haben schliesslich ihre Entsprechung. Also erstmal "r" (keyboard zurück) und "e" (sigterm) drücken und dann mehrere Sekunden warten, bis man mit "i" (sigkill) weitermacht. Das Problem trat bei mir bisher nur bei sehr grossen Dateien auf. Ich schlussfolgere mal, dass der Prozess nicht abrupt (sigkill) beim Schreiben unterbrochen werden darf.

Richtig, ich möchte noch hinzufügen, dass es hilfreich ist, wenn man die Festplatten-LED ein wenig im Blick hat und erst ein paar Sekunden wartet, nachdem die Festplatten-LED erloschen ist, bevor man den nächsten Buchstaben drückt. Je nach Systemauslastung kann es schon mal etliche Sekunden dauern, bis der aktuelle REISUB-Schritt abgeschlossen ist. Deswegen ist es schwer, die Wartezeit in absoluten Zahlen auszudrücken.