ups - gibts ein Undelete unter Linux ?

Zitat

Original von sigiberlin
ich nehme mal an, die krieg ich nicht mehr wieder, oder ?

kommt aufs dateisystem an. bei ext2 konnte man noch glueck haben, bei ext3 keine chance.

Sofort in den single-user-mode gehen und alle daemonen stoppen. Die betroffene Partition auf read-only setzen "mount -o remount,ro <mountpoint>"

Weiteres Vorgehen hängt vom verwendeten Dateisystem ab. Für einige existieren Undelete tools, die können normalerweise genau dann was wiederherstellen, wenn die Blöcke noch nicht mit anderen Daten beschrieben wurden, deshalb die Sofortmaßnahmen oben.

edit: Wieso sollte bei ext3 nichts gehen? Das Journal ändert ja nichts am Verhalten des FS beim Löschen von Files, das sieht genau gleich aus wie bei ext2.

edit2: Für die Zukunft sei dir folgendes in deinem Shell startupfile (.bashrc, .zshrc, ...) empfohlen:

alias mv='mv -i'
alias cp='cp -i'
alias rm='rm -i'

Zitat

Original von zirias
edit: Wieso sollte bei ext3 nichts gehen? Das Journal ändert ja nichts am Verhalten des FS beim Löschen von Files, das sieht genau gleich aus wie bei ext2.

Die Frage hab ich geahnt Aus der ext3-FAQ:

Q: How can I recover (undelete) deleted files from my ext3 partition?
Actually, you can't! This is what one of the developers, Andreas Dilger, said about it:

In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas
ext2 just marks these blocks as unused in the block bitmaps and marks the inode as "deleted" and leaves the block pointers alone.

Your only hope is to "grep" for parts of your files that have been deleted and hope for the best.

Hui, das is ja rabiat :o Die Begründung, warum das nötig ist, kann ich in dem Fetzen zwar nicht nachvollziehen -- aber die Konsequenz ist natürlich klar.

Zitat

Original von zirias
Hui, das is ja rabiat :o Die Begründung, warum das nötig ist, kann ich in dem Fetzen zwar nicht nachvollziehen -- aber die Konsequenz ist natürlich klar.

Nimm einfach an, Du hast gerade das Kommando zum Löschen einer grossen Datei abgesetzt. Die ersten paar Bloecke sind gelöscht. Ein anderer Prozess schreibt und schliesst eine kleinere Datei. Dabei werden zufaellig ein paar Blöcke, die gerade frei wurden, neu belegt. Das System crasht, bevor das Löschen der grossen Datei beendet ist. Beim Replay des Journals wird das Löschen dann fortgesetzt. Wenn die Pointer auf die bereits gelöschten (und teilweise schon wieder neu vergebenen) Blöcke jetzt nicht genullt worden wären - oops.

Zitat

Original von zirias
Sofort in den single-user-mode gehen und alle daemonen stoppen. Die betroffene Partition auf read-only setzen "mount -o remount,ro <mountpoint>"

Und genau das KANN der groesste Fehler sein.
Hier zeigt sich einer der grossen Unterschiede von Linux und Windows. Windows verweigert schlicht das Loeschen, wenn ein Prozess noch darauf zugreift. Linux loescht nur den Dateipointer. Der eigentliche Platz wird erst freigegeben, wenn der letzte Prozess beendet wurde.
D.h. wenn in diesem Fall die Datenbankdatei geloescht wurde, waehrend die Datenbank selbst noch laeuft, kann man noch problemlos auf die Datenbank zugreifen und z.B. eine entsprechende Sicherung machen. Erst, wenn der DB-Prozess beendet ist, geht garnix mehr. Und das wechseln in den Single-User Modus beendet den Datenbankprozess: VERLOREN!

Man könnte natürlich auch jeden als frei markierten Block einzeln im Journal vermerken, dann gäbe es das Problem nicht

Zitat

Original von zirias
Man könnte natürlich auch jeden als frei markierten Block einzeln im Journal vermerken, dann gäbe es das Problem nicht

Dafür dann eins mit der Performance Jede Blockoperation einzeln loggen (und syncen!)... Dafür möchtest Du mindestens ein separates Volume für das Journal. Am besten eine SSD.

Zitat

Original von knebb

Und genau das KANN der groesste Fehler sein.

Ich glaube kaum, dass jemand auf dcie Idee kommt, ein "undelete" zu benutzen, solange er in einem Programm noch Zugriff auf die Daten hat, von daher: eher nicht.

Zitat

Hier zeigt sich einer der grossen Unterschiede von Linux und Windows. Windows verweigert schlicht das Loeschen, wenn ein Prozess noch darauf zugreift. Linux loescht nur den Dateipointer. Der eigentliche Platz wird erst freigegeben, wenn der letzte Prozess beendet wurde.

Genaugenommen wird nur ein Link gelöscht...

Zitat

D.h. wenn in diesem Fall die Datenbankdatei geloescht wurde, waehrend die Datenbank selbst noch laeuft, kann man noch problemlos auf die Datenbank zugreifen und z.B. eine entsprechende Sicherung machen. Erst, wenn der DB-Prozess beendet ist, geht garnix mehr. Und das wechseln in den Single-User Modus beendet den Datenbankprozess: VERLOREN!

Wie gesagt, wenn der Prozess noch läuft ist es von vorneherein sinnlos, über "undelete" nachzudenken. Und in jedem anderen Fall kann man nur so schnell wie möglich alle Prozesse beenden, die potentiell Daten schreiben.

Zitat

Original von linuxservice

Dafür dann eins mit der Performance Jede Blockoperation einzeln loggen (und syncen!)... Dafür möchtest Du mindestens ein separates Volume für das Journal. Am besten eine SSD.

Das ist ein "klein wenig" übertrieben, Man kommt allerdings auch sehr schnell zu anderen Lösungen, wenn man drüber nachdenkt (z.B. zweite Bitmap, in der "gelöschte" Blocks markiert werden und nach Absschluss des Löschvorgangs wieder de-markiert). Der Punkt ist wohl eher, dass "man ja kein undelete braucht"

Zitat

Original von zirias
Das ist ein "klein wenig" übertrieben, Man kommt allerdings auch sehr schnell zu anderen Lösungen, wenn man drüber nachdenkt (z.B. zweite Bitmap, in der "gelöschte" Blocks markiert werden und nach Absschluss des Löschvorgangs wieder de-markiert).

Letztlich läuft es darauf hinaus, ob Allozieren und Deallozieren von Blöcken als nebenläufige Operationen erlaubt sein sollen oder nicht. Letzteres killt die Performance, weil es unnötig serialisiert.

Zitat

Der Punkt ist wohl eher, dass "man ja kein undelete braucht"

Braucht man auch nicht. Im Zweifelsfall funktionierts ja eh nicht, also sollte man besser gleich davon ausgehen, dass man es nicht hat.

Zitat

Original von linuxservice

Letztlich läuft es darauf hinaus, ob Allozieren und Deallozieren von Blöcken als nebenläufige Operationen erlaubt sein sollen oder nicht. Letzteres killt die Performance, weil es unnötig serialisiert.

Also eigentlich serialisiert das Beispiel da oben in Klammern gar nichts.

Außerdem ist Serialisierung von Jobs bei einem Dateisystem zumindest für traditionelle Festplatten etwas gutes und erhöht den Durchsatz. Kopfbewegungen sind nämlich teuer. Solange die Bursts nicht zu groß werden, wirkt sich das auch nicht spürbar negativ auf Antwortzeiten aus.

Zitat

Original von zirias
Also eigentlich serialisiert das Beispiel da oben in Klammern gar nichts.

Eigentlich hatte ich das auch länger ausgeführt, dann aber wegen zunehmendem off-topic auf das wesentliche zusammengekürzt, vielleicht etwas zu weit. Wieviele "zweite Bitmaps" bräuchtest Du für volle Nebenläufigkeit, wo liegen die (Abwärtskompatibilität zu ext2) und wie gross kann eine "zweite Bitmap" überhaupt maximal sein?

Damit will ich nicht sagen, dass es gar keine bessere Lösung geben kann als die existierende, nur dass man vermutlich die einfache und offensichtliche genommen hat, weil es in Dateisystemen selten eine gute Idee ist, die Dinge unnötig zu verkomplizieren und es schließlich "nur" das Undelete kostet.

Zitat

Außerdem ist Serialisierung von Jobs bei einem Dateisystem zumindest für traditionelle Festplatten etwas gutes und erhöht den Durchsatz. Kopfbewegungen sind nämlich teuer. Solange die Bursts nicht zu groß werden, wirkt sich das auch nicht spürbar negativ auf Antwortzeiten aus.

Wie das Dateisystem intern mit seinen Aufgaben umgeht, ist was anderes. Auf dem externen Interface will der Userspace eher nicht "warte mal, ich kann gerade nicht" hören. Abgesehen davon, dass es dem Dateisystem und den unterliegenden Ebenen Optimierungsmöglichkeiten nimmt, wenn man alles stur sequentiell macht.

Zitat

Original von linuxservice
Wie das Dateisystem intern mit seinen Aufgaben umgeht, ist was anderes.

Eigentlich nicht. Wenn man gewisse Garantien geben will (wie z.B. dass ein read() call, der nach der Rückkehr von einem write() call durchgeführt wird, die neuen Daten liefern muss), muss man immer Prozesse blocken. Will man den Durchsatz durch stärkere Serialisierung erhöhen, werden vereinzelt eben die block-Zeiten länger.

Zitat

Auf dem externen Interface will der Userspace eher nicht "warte mal, ich kann gerade nicht" hören. Abgesehen davon, dass es dem Dateisystem und den unterliegenden Ebenen Optimierungsmöglichkeiten nimmt, wenn man alles stur sequentiell macht.

Also zunächst mal: Das Dateisystem ist es, wovon ich rede. Anwendungen serialisieren ihr IO nicht (das ist meistens eh schon "seriell").

Ob man kurze Antwortzeiten oder hohen Datendurchsatz bevorzugt ist zunächst mal eine Frage des Einsatzgebiets. Bei einem Server, bei dem die Platte eigentlich nie steht (z.B. Webserver) ist es durchaus wünschenswert, einzelne IO-Calls zu blockieren, um andere an einem Stück durchlaufen zu lassen -- sonst kommt der Server noch früher an seine Auslastungsgrenze. Diese Art der Optimierung auf Durchsatz können untere Schichten machen und das Resultat ist eben, dass einige IO-Calls länger blocken.

Zitat

Original von zirias
Eigentlich nicht. Wenn man gewisse Garantien geben will (wie z.B. dass ein read() call, der nach der Rückkehr von einem write() call durchgeführt wird, die neuen Daten liefern muss), muss man immer Prozesse blocken. Will man den Durchsatz durch stärkere Serialisierung erhöhen, werden vereinzelt eben die block-Zeiten länger.

Wir werden langsam ernsthaft off-topic und wie mir scheint, diskutieren wir auch zunehmend aneinander vorbei. Also nur noch eine Abschlussnotiz: Dass es hier und da sinnvoll oder sogar erwünscht (blocking IO) sein kann, zu serialisieren, ist unbestritten (deshalb schrieb ich ja: Wie das Dateisystem intern mit seinen Aufgaben umgeht, ist was anderes). Aber es ist im allgemeinen nicht performancedienlich, Sachen, die sinnvoll parallel bearbeitet werden könnten, ohne Not nur noch sequentiell abzuarbeiten.

Zitat

Original von linuxservice
Wir werden langsam ernsthaft off-topic und wie mir scheint,

Off-Topic ist das schon lange ... na und? Leider ist das ein Webforum, mal eben ordentlicher Subject-Wechsel ist nicht...

Zitat

diskutieren wir auch zunehmend aneinander vorbei. Also nur noch eine Abschlussnotiz: Dass es hier und da sinnvoll oder sogar erwünscht (blocking IO) sein kann, zu serialisieren, ist unbestritten

Sorry, aber das eine hat mit dem anderen so gar nichts zu tun. Blocking I/O ist "Standard" auf Unix-Systemen, ganz egal ob das ein high-bandwith-server oder ein low-latency-desktop sein soll. und ob nun blocking oder non-blocking: Serialisierung (eigentlich der falsche Begriff, hier geht's einfach um große Bursts) sorgt einfach dafür, dass Wartezeiten im Einzelfall länger sein können, insgesamt aber der Durchsatz höher wird.

Zitat

(deshalb schrieb ich ja: Wie das Dateisystem intern mit seinen Aufgaben umgeht, ist was anderes). Aber es ist im allgemeinen nicht performancedienlich, Sachen, die sinnvoll parallel bearbeitet werden könnten, ohne Not nur noch sequentiell abzuarbeiten.

Performance ist kein absoluter Parameter, bandwith vs. latency ein altbekannter trade-off. Und "sinnvoll parallel" ist bei Festplatten an sich schon ein Widerspruch, zumindest solange der gleiche Bereich (Kopf) der Platte betroffen ist.

Zitat

Original von zirias
Sorry, aber das eine hat mit dem anderen so gar nichts zu tun. Blocking I/O ist "Standard" auf Unix-Systemen, ganz egal ob das ein high-bandwith-server oder ein low-latency-desktop sein soll.

Ist noch de-facto-Standard. POSIX AIO existiert.

Zitat

und ob nun blocking oder non-blocking: Serialisierung (eigentlich der falsche Begriff, hier geht's einfach um große Bursts) sorgt einfach dafür, dass Wartezeiten im Einzelfall länger sein können, insgesamt aber der Durchsatz höher wird.

_Dir_ gehts hier aus mir nicht ganz nachvollziehbaren Gründen seit einigen Postings um grosse Bursts und die Tatsache, dass es für das Dateisystem unter Umständen performancesteigernd sein kann, auch mal ein paar mehr Blocks am Stück zu lesen. Das ist aber eine interne Entscheidung des Dateisystems und das hat hier auch niemand in Frage gestellt. _Mir_ ging es darum, dass es keine gute Idee waere, die Requests von vornherein zu serialisieren, also z.B. ein unlink zu blocken, nur weil schon eins läuft. (oder keine Bloecke zu allozieren, solange jemand welche freigibt, und umgekehrt).

Zitat

Performance ist kein absoluter Parameter, bandwith vs. latency ein altbekannter trade-off. Und "sinnvoll parallel" ist bei Festplatten an sich schon ein Widerspruch, zumindest solange der gleiche Bereich (Kopf) der Platte betroffen ist.

Bei geeigneter Performancemetrik ist sogar Batchprocessing optimal. Unbestritten. Aber in jeder realen Umgebung sollte das Dateisystem erstmal alle Requests annehmen, in die interne Bearbeitung aufnehmen und dann irgendwann quittieren. Oder sofort, wenns AIO oder ein unlink ist. Es kann der Applikation völlig egal sein, wann die Blöcke wieder freigegeben werden. Auf der Ebene ist noch fast alles "sinnvoll parallel". Im Dateisystem oder darunter macht man sich dann schon Gedanken über die sinnvolle Reihenfolge, und ob man vielleicht auf Verdacht schon mal was einliest, was bald gebraucht werden könnte, und da bietet Linux auch unterschiedliche IO-Scheduler zur Auswahl. Aber das _kann_ man erst gar nicht, wenn das Dateisystem serialisiert und von vornherein sagt, ich habe hier einen Request, den muss ich erstmal abschliessen, bevor ich mit dem nächsten überhaupt erst anfange. Das ist Batchprocessing.

So langsam wird klar, worauf du eigentlich rauswolltest: Der IO-Scheduler arbeitet hier auf Block-Ebene (?) (hab keine eindeutige Aussage dazu gefunden, da müsste man wohl direkt den Code lesen, wenn man es genau wissen will?)

Wenn das so ist muss er natürlich auf der ebene noch die Chance haben, Entscheidungen zu treffen, richtig. Allerdings hat das nichts damit zu tun, dass eine Anwendung so oder so (bei sync IO, also normalerweise) geblockt wird, bis ihre Anfrage beendet ist -- deine erste Antwort hat mich daher in ne falsche Richtung denken lassen. Um die Schnittstelle zwischen Kernel- und Userspace geht's doch dann gar nicht