klassikmann hat geschrieben:Das habe ich anders interpretiert: Gestern liefen keine Autostart-TAPs und Timeshift war deaktiviert. Da hat mich der Nicht-Freeze kaum gewundert, auf der Platte war einfach "nichts los". Heute jedoch habe ich im "Standard-Modus", also mit TAPs und Timeshift getestet.
Sorry, das hab ich dann wohl falsch verstanden...
Aber ich wage trotzdem zu bezweifeln, dass ein "Schneiden" einen Freeze in einem anderen TAP verhindern kann... könnte ich mir zumindest technisch nicht erklären (obwohl es da ja noch ein paar mehr Sachen gibt, die ich nicht erklären kann^^)
klassikmann hat geschrieben:Direkt nach dem Neustart! Ich bleibe dabei, ein fsck auf einem gemounteten Filesystem ist im r/o-Modus nicht aussagekräftig und kann im r/w-Modus die Platte völlig ruinieren. Deswegen habe ich die Logs auch als 'unspektakulär' bezeichnet.
Wo du recht hast, hast du recht.
Aber Fakt ist nunmal auch, dass wir hier einem Problem mit einem inkosistenten FileSystem auf der Spur sind, welches Dateien verliert. Wenn wir also von fsck irgendwelche Meldungen bekommen, die genau darauf hinweisen, dann sollten wir denen möglichst auch nachgehen.
Nach meiner Interpretation ist es so:
Während ein Dateisystem gemountet ist,
darf es gelegentliche kurzzeitige Inkonsistenzen aufweisen, da Schreiboperationen nicht atomar durchgeführt werden. z.B. werden während einer Aufnahme vermutlich permanent neue Blöcke im Voraus reserviert und vollgeschrieben - der Eintrag ins Dateisystem erfolgt dann aber erst später...
Deshalb zeigt fsck einen Fehler an (der zu dem Zeitpunkt auch tatsächlich vorhanden ist), der aber nicht kritisch ist (und keinesfalls "repariert" werden sollte), da das FS noch dabei ist, den Zustand selbst wieder richtigzustellen...
Das ist der Grund, warum fsck niemals ein gemountetes System reparieren sollte. Und warum in gemountetem Zustand manchmal "Phantom-Fehler" angezeigt werden, die kurze Zeit später wieder verschwunden sind.
Aber fsck "erfindet" auch in gemountetem Zustand nicht einfach irgendwelche Fehler, die nicht zu dem Zeitpunkt gerade vorhanden sind (wenn auch nur temporär).
Und es könnte durchaus möglich sein, dass irgendein HDD-Zugriff während eines solchen Zustands der temporären Inkonsistenz stattfindet, und somit unser allerseits gefürchtetes Phänomen verursacht.
Ich schlage also vor, dass wir (um wichtige von unwichtigen Fehlern zu unterscheiden) bei künftigen fscks folgendes tun:
- vor dem fsck möglichst alle gleichzeitigen Schreibzugriffe abschalten (insbesondere Aufnahmen und Timeshift)
- vor dem fsck einmal 'sync' aufrufen, um das FS anzuweisen, anstehende Schreiboperationen jetzt durchzuführen
- abwarten, bis das passiert (eine halbe bis ganze Sekunde sollte reichen)
- jetzt zur Sicherheit noch ein hdparm -f
- fsck mit den Parametern -n und -v aufrufen, und die (hoffentlich nur wenigen) Meldungen, die dabei entstehen, ernst nehmen
klassikmann hat geschrieben:Wenn ich Zeit habe, baue ich vielleicht die Festplatte aus und schaue mir die Misere mit dem "UFS Explorer" an.
Das wäre natürlich auch eine ziemlich coole Idee. Oder auch als externe Platte an den Topf anschließen, und dann in ungemountetem Zustand mit fsck prüfen (dafür muss die Platte nichtmal ausgebaut, sondern nur per e-SATA angeschlossen werden ;-))
Und ich werde als nächstes eine MC-Version erstellen, die nach dem Schnitt selbstständig ein fsck durchführt und das Log auf verdächtige Einträge untersucht.
Das erspart uns viel Aufwand beim künftigen Debuggen, und v.a. es ermöglicht wenigstens den Benutzer rechtzeitig zu warnen, falls seine Aufnahmen beim nächsten Start verschwinden - so dass er zuvor noch ausreichend Gelegenheit hat, sie zu sichern ;-)
Und v.a. nicht neue Dateien defekt sein...
Meine aktuellen TAPs: 
Sollte die Beschädigung des Dateisystems durch einen irgendwann auftretenden Pufferüberlauf ausgelöst werden, ist ja nicht nur das komplette MC verdächtig, und da hat sich seit der V1.4 viel getan, sondern auch ein Großteil der FireBirdLib, die eine Menge Funktionen zur Verfügung stellt. Und dass praktisch nur eine Person Aufnahmen halbwegs auf Befehl verschwinden lassen kann, macht das Debuggen auch nicht einfacher.