Adalbert Michelic wrote:

* On Tue, 14 Jan 2003 at 20:33 +0100, Jörg Ries wrote:

...

bin am verzweifeln. Habe mir soeben versehntlich wichtige Dateien auf einer ReiserFS-Partition gelöscht.

Gibt es eine Möglichkeit da wieder dran zu kommen?

Sofort Finger von der Partition weg, unmounten, auf Backup-Volume duplizieren und auf dem Backup-Volume reiserfsck --rebuild-tree laufen lassen.

Was sollte das denn bei geloeschten Dateien bringen? Es ist ja nicht so, dass das Filesystem einen Schaden hat o.ae. - die Da- teien wurden einfach regulaer geloescht, und damit ist die Sache doch auch fuer das Journaling Filesystem laengst geges- sen... Bei ext2 koennte man vielleicht noch was retten mit et- was Aufwand, aber bei ReiserFS? CU, Th. -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe

---- Original Message ----- From: "Hartmut Meyer" To: Sent: Tuesday, January 14, 2003 9:48 PM Subject: Re: Dateien auf ReiserFS wiederherstellen

Hallo,

Am Dienstag, 14. Januar 2003 20:39 schrieb Adalbert Michelic:

...

* On Tue, 14 Jan 2003 at 20:33 +0100, Jörg Ries wrote:

...

bin am verzweifeln. Habe mir soeben versehntlich wichtige Dateien auf einer ReiserFS-Partition gelöscht.

Gibt es eine Möglichkeit da wieder dran zu kommen?

Sofort Finger von der Partition weg, unmounten, auf Backup-Volume duplizieren und auf dem Backup-Volume reiserfsck --rebuild-tree laufen lassen.

Ich bezweifle ganz stark, dass das was bringt

naja, einen Versuch ist es ja wert. Diesen Versuch realisiere ich über's LAN auf meinen anderen PC (WindowsXP). Bei 2GB hat er allerdings abgebrochen mit der Meldung "File size limit exceeded" Die zu rettende Partition hat 25GB wovon etwa 12GB belegt sind. Welche Methode könnte es noch geben? gzip -9 < /dev/hda5 > /winlan/save/image.img meldet den gleichen Fehler. Danke erstmal, Jörg

---- Original Message ----- From: "Hartmut Meyer" To: Sent: Tuesday, January 14, 2003 11:03 PM Subject: Re: Dateien auf ReiserFS wiederherstellen [...]

...

Diesen Versuch realisiere ich über's LAN auf meinen anderen PC

(WindowsXP).

...

Bei 2GB hat er allerdings abgebrochen mit der Meldung "File size limit exceeded" Die zu rettende Partition hat 25GB wovon etwa 12GB belegt sind. Welche Methode könnte es noch geben? gzip -9 < /dev/hda5 > /winlan/save/image.img meldet den gleichen Fehler.

Du kannst dir die Mühe sparen. Ernsthaft.

Deine Daten sind weg. Ende Gelände. Kein Scherz.

Da kommt nun ne Menge Arbeit auf mich zu. Trotzdem Danke für die schnellen Antworten. Gruss Jörg

Hallo, Am Dienstag, 14. Januar 2003 23:17 schrieb Andreas Feile:

Hartmut Meyer, Dienstag, 14. Januar 2003 23:03:

...

Ich hätte das deutlicher schreiben können: es bringt nix! Kann es nicht.

Dieser Link http://marc.theaimsgroup.com/?l=reiserfs&m=102897202005397&w=2 wurde ja zuvor schon gepostet. Wenn es ist wie Du sagst, wie konnte "Z." dann wieder an seine Daten kommen?

Zitat aus der von dir genannten URL: "I guess this only worked because immediatly unmounted the partition after my unfortunate error to prevent writing new nodes and data." Man beachte vor allem "to prevent writing new nodes and data". Das dürfte 1. riesen Glück gewesen sein und 2. auf Jörg nicht zutreffen. Schöne Grüße aus Bremen hartmut

Hartmut Meyer wrote:

...

1. riesen Glück gewesen sein und 2. auf Jörg nicht zutreffen.

Ich nehme alles zurück und behaupte das Gegenteil!

*huch*, wie kommt dieser sinneswandel? micha

Hartmut Meyer wrote:

[...] Ich habe offensichtlich daneben gelegen. Das wurde in diesem Thread ja wohl erwiesen.

Naja, ich habe da eigentlich genau so gedacht wie Du... Die Frage, die sich mir nun stellt, ist: Wie kann das technisch ueberhaupt funktionieren? Ich kenne natuerlich keine internen Details zu den Journaling Filesystemen, d.h. auch nicht zu ReiserFS. Warum also kann ein neuer Aufbau des Trees (und das war es wohl, was gehol- fen hat) geloeschte Dateien wieder herstellen? Hat da jemand eine Erklaerung dazu? Gruesse, Th. -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe

Am Donnerstag, 16. Januar 2003 00:25 schrieb Andreas Feile: Hallo zusammen,

Ich verstehe jetzt Dein Problem nicht ganz. Ob ich nun ein Journal habe oder nicht: in den paar Sekunden, in denen ein rm -rf arbeitet, kann unmöglich die ganze Platte gelöscht, also mit Nullen oder sowas beschrieben werden. Ergo: Die Dateien sind noch da, nur halt nicht zu sehen. Wenn ich jetzt also den gesamten Platz der Platte scanne, dann ist es doch durchaus vorstellbar, daß ich die ursprünglichen Dateien wiederkriege. Vielleicht nicht mit ihrem Namen, aber immerhin.

Wäre jetzt mal interessant zu wissen, ob Jörg auch seine Dateinamen wiedergekriegt hat...

Auf meiner Partition gemountet als /backup gab es (auszugsweise) folgende Verzeichnistruktur: /backup |- [download] |- [treiber] |- [sichern] |- [texte] |- [webseiten] |- [midis] |- outlook.pst Mein Prompt zeigte "meinpc:/backup #" als ich den Befehl "rm -R *" ausführte. Obwohl ich den Irrtum sofort bemerkte und mit STRG+C den Vorgang abbrach, war das Verzeichnis download, webseiten, texte und die Datei outlook.pst weg. Nach eben diesem reiserfsck hatte ich ein Verzeichnis "lost+found". Dort befanden sich jede Menge (so um die 90.000) Dateien und Verzeichnisse. Die Dateien und Verzeichnisse in "/backup/lost+found" hatten Namen nach dem Muster "105695-6595". Aber das erste Unterverzeichnis mit weiteren Dateien und Verzeichnisse hatten genau die Namen, mit welchen ich diese angelegt habe. Also: /backup/lost+found/32560-6321/Treiber". Daran erkannte ich, dass das Verzeichnis 32560-6321 in download umbenannt werden muss. Die Datei outlook.pst konnte ich nur über die mir bekannte Dateigrösse erahnen. Die Platte, auf welcher sich jetzt mein Linux befindet, war ursprünglich ein Windows2000 PC. Nach dieser Aktion, hatte ich auch Dateien von diesem System wieder zum Vorschein gebracht, z. Bsp. mein damaliges Startmenü. Hatte mich etwas gewundert, denn auf diese Platte sind mehrere Male Suse Linux, Windows2000 und WindowsXP installiert worden. Meist wurde dabei auch neue Partitionen vergeben. Das mal soweit zu meiner gestrigen Erfahrung. Sollten euch noch weitere Fragen zu diesem Vorfall quälen, ich berichte gerne noch darüber. Grüsse Jörg

Hallo, Am Donnerstag, 16. Januar 2003 00:50 schrieb Joerg Ries: [...]

Mein Prompt zeigte "meinpc:/backup #" als ich den Befehl "rm -R *" ausführte. Obwohl ich den Irrtum sofort bemerkte und mit STRG+C den Vorgang abbrach, war das Verzeichnis download, webseiten, texte und die Datei outlook.pst weg.

Aah! Jetzt wird es mir wieder verständlicher, bzw. die Sache nachvollziehbarer. Du hast den verheerenden "rm" Befehl noch vor Vollendung abgebrochen. Damit dürften nur Teile des eigentlichen Löschens (Ändern der Verwaltungsstrukturen im Dateisystem) geschehen sein. Wenn das Verzeichis "download" tatsächlich schon gelöscht war, aber die Unterverzeichnisse und darin liegende Dateien nicht, dann waren die Verwaltungsstrukturen ancshließend inkosistent. Genau das aber kann reiserfsck reparieren. Ich war davon ausgegangen, dass du deinen Fehler erst deutlich später bemerkt hättest. Dann allerdings wären die Verwaltungsinformationen konsistent (alle Daten weg) und reiserfsck hätte auch nichts mehr retten können. Hat vielleicht mal jemand Lust das zu testen? Würde hier bestimmt ne Menge Leute interessieren! Schöne Grüße aus Bremen hartmut

Andreas Feile schrieb am 16.01.2003 um 00:25:13 +0100: Hallo Andreas,

Thomas Hertweck, Mittwoch, 15. Januar 2003 21:32:

...

Naja, ich habe da eigentlich genau so gedacht wie Du... Die Frage, die sich mir nun stellt, ist: Wie kann das technisch ueberhaupt funktionieren? Ich kenne natuerlich keine internen Details zu den Journaling Filesystemen, d.h. auch nicht zu ReiserFS. Warum also kann ein neuer Aufbau des Trees (und das war es wohl, was gehol- fen hat) geloeschte Dateien wieder herstellen? Hat da jemand eine Erklaerung dazu?

Ich verstehe jetzt Dein Problem nicht ganz. Ob ich nun ein Journal habe oder nicht: in den paar Sekunden, in denen ein rm -rf arbeitet, kann unmöglich die ganze Platte gelöscht, also mit Nullen oder sowas beschrieben werden. Ergo: Die Dateien sind noch da, nur halt nicht zu sehen. Wenn ich jetzt also den gesamten Platz der Platte scanne, dann ist es doch durchaus vorstellbar, daß ich die ursprünglichen Dateien wiederkriege. Vielleicht nicht mit ihrem Namen, aber immerhin.

aber auch nur dann, wenn der Befehl nicht bis zum Schluss ausgeführt worden ist, da dann das Journal noch nicht geschrieben wurde und ein neu aufbauen des Tress dann Fehler feststellt und diese versucht zu beheben. Auch wenn das nur ein sammeln von Dateibruchstücken ist. Wenn ein "rm /was/auch/immer" durchgelaufen ist, kann und wird auch ein neu aufbauen des Tress absolut nichts bringen, egal ob die Daten noch auch der Platte sind oder schon überschrieben, da für Reiser diese Daten nicht mehr existieren, da schon das Journal geschrieben wurde.

Wäre jetzt mal interessant zu wissen, ob Jörg auch seine Dateinamen wiedergekriegt hat...

er hat in seinem Fall nur Riesenglück gehabt. Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de

Thomas Hertweck, Donnerstag, 16. Januar 2003 09:19:

Nein, Du hast das Problem nicht verstanden.

Nein, Du... ;)

Ein --rebuild-tree _kann_ die geloeschten Dateien nicht wieder herstellen, wenn bereits der Befehl komplett abgearbeitet wurde. Das Filesystem ist dann korrekt und das Journaling Log fuer den Vorgang ist AFAIK nicht mehr verfuegbar. Somit kann auch von reiserfsck nichts wieder hergestellt werden.

Ich verstehe nicht, was ihr alle mit eurem Journal wollt. Wenn ich ein rm mache und selbiges dann mit strg-c abbreche, dann hinterläßt das doch kein inkonsistentes Filesystem. Der Befehl hört hat nur früher als geplant auf zu arbeiten.

Stelle Dir mal vor, dann muesste ein --rebuild-tree ja nach Deiner Theorie alle Daten, die ich jemals geloescht habe und die noch nicht wieder physikalisch ueberschrieben wurden, wiederherstellen. Das kann nicht sein.

Ein --rebuild-tree holt nicht alle Daten zurück. Aber ein --rebuild-tree --scan-whole-partition aber halt uU schon.

IMHO liegt es daran, wie von Hartmut auch schon gesagt, dass der Befehl abgebrochen wurde.

Das ist Unsinn, denn wenn es so wäre, wie Du sagst, dann müßte Jörg ja abgebrochen haben, just als gerade *alle* Dateien hätten gelöscht werden sollen. Denn er hat ja auch alles wiedergekriegt. Sorry, aber das ist doch echt Quatsch. Und wie erklärst Du Dir, daß er sogar Dateien von seiner alten w2-Installation wiedergesehen hat? War da Deiner Meinung nach auch gerade rm am Werk und wurde bedauerlicherweise unterbrochen? -- Andreas Feile www.feile.net

Am Don, 2003-01-16 um 10.25 schrieb Thomas Hertweck:

Wenn ich auf einem Dateisystem, was korrekt ist (und das ist es ja, da, wie Du gesagt hast, der Abbruch zu keinem inkonsi- stenten Filesystem fuehrt),

Allein schon mit der Aussage, daß das Filesystem konsistent und damit nicht defekt ist, widerspricht dem Sinn das es funktionieren kann. Schließlich ist es kein "undelete" sondern ein "fsck". Ich kann der manpage auch nicht entnehmen, das reiserfsck für solche zwecke konzipiert wurde: "Reiserfsck searches for a Reiserfs filesystem on a device, replays any necessary transactions, and either checks or repairs the file system." Auch der folgende Text zur Option "--rebuild-tree" kann mich davon nicht überzeugen: "This option rebuilds the entire file system tree using leaf nodes found on the device. Normally you only need this option if the --check option reports "corruption that can be fixed only during --rebuild-tree". You are strongly encouraged to make a backup copy of the whole partition before attempting the --rebuild-tree option." Ciao, Torsten

* On Fri, 17 Jan 2003 at 21:12 +0100, Thomas Hertweck wrote:

Torsten Hallmann wrote:

...

Am Don, 2003-01-16 um 10.25 schrieb Thomas Hertweck:

...

Wenn ich auf einem Dateisystem, was korrekt ist (und das ist es ja, da, wie Du gesagt hast, der Abbruch zu keinem inkonsi- stenten Filesystem fuehrt),

Allein schon mit der Aussage, daß das Filesystem konsistent und damit nicht defekt ist, widerspricht dem Sinn das es funktionieren kann. Schließlich ist es kein "undelete" sondern ein "fsck".

Genau das ist es, was ich schrieb. Aber anscheinend hat niemand eine Erklaerung fuer das Vorgehen, selbst diejenigen nicht, die in diesem Thread davon berichteten, dass es funktioniert (bzw. so funktionieren muss). Zumindest hat sich niemand gemeldet - mir jedenfalls leuchtet das Verhalten von reiserfsck nicht ein.

Beim L;schen einer Datei wird ja nicht der Inhalt der Datei geloescht, sondern nur die Zuordnung des Veryeichniseintrages zum Inode, ausserdem werden im Bitmap die entsprechenden Bloecke freigegeben. reiserfsck baut den kompletten Tree neu auf, findet einen unverlinkten Inode, h'ngt ihn unter lost+found ein und markiert die Blocke wieder als belegt. Details finden sich in und unterhalb von /usr/src/linux/fs/reiserfs/. Kann gutgehen und man hat sein Yeug wieder, oder auch nicht. In diesem Falle hat man hoffentlich ein Band herumliegen ... -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at

* On Fri, 17 Jan 2003 at 23:18 +0100, Thomas Hertweck wrote:

Adalbert Michelic wrote:

...

[...] Beim L;schen einer Datei wird ja nicht der Inhalt der Datei geloescht, sondern nur die Zuordnung des Veryeichniseintrages zum Inode, ausserdem werden im Bitmap die entsprechenden Bloecke freigegeben. reiserfsck baut den kompletten Tree neu auf, findet einen unverlinkten Inode, h'ngt ihn unter lost+found ein und markiert die Blocke wieder als belegt. Details finden sich in und unterhalb von /usr/src/linux/fs/reiserfs/.

Zitat Philipp Thomas (Sun, 12 Jan 2003 03:27:26 +0100): "Das ist reiserFS, richtig? Reiserfs verwendet keine Inodes, daher ist die Zahl immer gleich."

adalbert@pepe:~ > grep -ir inode /usr/src/linux/fs/reiserfs/ | wc -l 1857 Scheinbar weiss ReiserFS aber noch nichts davon, dass es keine Inodes verwendet. Wuerde, soweit ich weiss, auch erhebliche Schwierigkeiten mit dem VFS geben. Wenn ich Thomas' Aussage richtig stellen darf: ReiserFS belegt im Gegensatz zu ext[23] nicht einen fixen Teil der Platte mit Inodes, sondern allokiert diese nach Bedarf. Die Anzahl der freien Inodes ist also nur durch die zur Verfuegung stehende Plattenkapayitaet begrenzt.

Zitat Bernd Brodesser (2002-10-31 10:37:19): "Marcel hat geschrieben, daß er ReiserFS hat, und da gibt es kein lost+found. lost+found gehört zu einem Dateisystem. Jedes ext2 Dateisystem hat sein eigenes lost+found. Da bei Dir wohl /boot ein eigenes Dateisystem darstellt [1] gibt es dort auch ein lost+found. Wenn bei Dir / ein reiserFS ist, gibt es dazu kein lost+found, da Reiser sowas nicht hat."

Wer sollte reiserfsck verbieten ein lost+found anzulegen? Die Tatsache, dass ein frisches ext2 ein lost+found hat, ReiserFS hingegen nicht, sagt ja noch nicht sonderlich viel ueber das, was reiserfsck macht/machen kann aus. Und solange Joerg in <200301160050.15623.linux@around-web.de> nicht gemogelt hat, hatte er ein lost+found, warum sollte man ihm das nicht glauben? -- Adalbert, hoffend alle Fipptehler eliminiert zu haben ... GPG welcome, request public key: mailto:adalbert+key@lopez.at

* Joerg Ries schrieb am 18.Jan.2003:

Am Freitag, 17. Januar 2003 23:49 schrieb Adalbert Michelic:

...

Wer sollte reiserfsck verbieten ein lost+found anzulegen? Die Tatsache, dass ein frisches ext2 ein lost+found hat, ReiserFS hingegen nicht, sagt ja noch nicht sonderlich viel ueber das, was reiserfsck macht/machen kann aus.

Und solange Joerg in <200301160050.15623.linux@around-web.de> nicht gemogelt hat, hatte er ein lost+found, warum sollte man ihm das nicht glauben?

Kann ich im Nachhinein nur nochmal bestätigen. Diese "Lost+Found" habe ich immer noch - definitiv unter _ReiserFS_

Es ist kein Problem ein Verzeichnis lost+found anzulegen, meinetwegen auch Lost+Found, was was ganz anderes ist, und auch ext2 nicht fänd, wenn es notwendig ist. Aber AFAIK ist es bei ReiserFS vollkommen unnutz. Wenn beim e2fsck irgenwelche Dateien gefunden werden, die nicht richtig gelöscht sind, aber nicht im Dateibaum mehr einhängbar sind, dann legt das System diese Dateien in lost+found, nicht Lost+Found, ab. Und zwar unter ihrer I-Node-Nummer. ReiserFS macht dies aber nicht. Jedes ext2-Dateisystem hat sein eigenes lost+found. Wenn z.B. /home ein eigenes ext2-Dateisystem ist, dann wird auch ein /home/lost+found angelegt. Und wenn /usr/local ein eigenes ext2-Dateisystem ist, so gibt es auch ein /usr/local/lost+found. Wenn man sich ein ReiserFS macht, so gibt es dort kein lost+found. Wenn man aber ein ext2 hat, und macht sich dann ein ReiserFS und kopiert das ext2 auf das neue ReiserFS so kopiert man natürlich auch das lost+found mit, ist ein normales Verzeichnis und wird selbstverständlich mitkopiert. Aber auf ReiserFS hat es AFAIK keine Funktion. Wie es bei ext3 oder anderen Dateisystemen aussieht weiß ich nicht. Ganz normal ist lost+found doch nicht. Einziger unterschied, lost+found ist von vorneherein größer als ein normales leeres Verzeichnis, damit genug Platz da ist, um da viel reinzuschreiben, denn in einem kaputten Dateisystem, und nur für diesen Fall ist lost+found da, auch noch Platz für das Verzeichnis zu schaffen ist widersinnig. Siehe aber auch andere Mail, vielleicht sieht es bei ReiserFS doch anders aus, als ich es mir vorgestellt habe. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11

* Joerg Ries schrieb am 18.Jan.2003:

Am Samstag, 18. Januar 2003 06:27 schrieb Bernd Brodesser:

...

Es ist kein Problem ein Verzeichnis lost+found anzulegen, meinetwegen auch Lost+Found, was was ganz anderes ist, und auch ext2 nicht fänd, wenn es notwendig ist. Aber AFAIK ist es bei ReiserFS vollkommen unnutz. Wenn beim e2fsck irgenwelche Dateien gefunden werden, die nicht richtig gelöscht sind, aber nicht im Dateibaum mehr einhängbar sind, dann legt das System diese Dateien in lost+found, nicht Lost+Found, ab. Und zwar unter ihrer I-Node-Nummer. ReiserFS macht dies aber nicht.

Ja, das Verzeichnis heist "lost+found" und dieses wurde erst angelegt, als ich reisfschk ausgeführt habe. Dort war dann unter einer Nummer (I-Node-Nummer?) die Dateien abgelegt, welcher er noch gefunden hat.

Ich kenne das mit #123 oder ähnlich, wobei 123 die I-Node-Nummer ist. Die I-Node-Nummer kann man sich mit ls -i ansehen und mit find suchen. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0

Hallo, On Fri, 17 Jan 2003, Adalbert Michelic wrote:

* On Fri, 17 Jan 2003 at 23:18 +0100, Thomas Hertweck wrote:

Jungs, wenn euch das Phaenomen wirklich interessiert, RTFS. Mich nicht (mehr)[1][2].

Adalbert, hoffend alle Fipptehler eliminiert zu haben ...

Mit y/z Drehern scheinst du aber noch Probleme zu haben... Tastaturlayout neulich de/us umgestellt und die alten Fingermakros sind noch aktiv? ;) -dnh [1] u.a. _weil_ ich mal RTFS in fs/reiserfs gemacht habe... Und RTF(LK|reiserfs)ML... Is zwar schon ne Weile her, aber... [2] neulich das letzte reiserfs (/var) auf ext3 umgestellt habend -- Die Tastatur finden Sie, indem Sie das Kabel verfolgen, ds mit einem 5poligen DIN-Stecker an der Rückseite Ihres Rechners angebracht ist. [CrossPoint-Hilfe]

Adalbert Michelic wrote:

[...] Und solange Joerg in <200301160050.15623.linux@around-web.de> nicht gemogelt hat, hatte er ein lost+found, warum sollte man ihm das nicht glauben?

Natuerlich kann ich ihm glauben, aber dann war eine der anderen zitierten Aussagen eben nicht ganz korrekt. Ich wollte nur wis- sen, wie es eigentlich richtig ist. So einfach, wie einge das versucht haben darzustellen (Motto: "Ganz klar, reisefsck muss genau so funktionieren") ist es jedenfalls nicht! Gruesse, Th. -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe

* Andreas Koenecke schrieb am 18.Jan.2003:

* Freitag, 17. Januar 2003 um 23:18 (+0100) schrieb Thomas Hertweck:

...

Zitat Bernd Brodesser (2002-10-31 10:37:19): "Marcel hat geschrieben, daß er ReiserFS hat, und da gibt es kein lost+found. lost+found gehört zu einem Dateisystem. Jedes ext2 Dateisystem hat sein eigenes lost+found. Da bei Dir wohl /boot ein eigenes Dateisystem darstellt [1] gibt es dort auch ein lost+found. Wenn bei Dir / ein reiserFS ist, gibt es dazu kein lost+found, da Reiser sowas nicht hat."

Das widerspricht meinen Erfahrungen: Nach einem 'reiserfsck --rebuild-tree' auf einem defekten Dateisystem fand ich auf dem Dateisystem ein Verzeichnis "/lost+found" mit vielen reparierten Dateien. (Natürlich nicht mit den richtigen Dateinamen.) Mit einem Rettungssystem und viel "Handarbeit" war es dadurch möglich, das System wieder komplett herzustellen.

Das ist interessant. Ich kenne ReiserFS nicht wirklich. Will sagen, weiß nicht, wie es genau arbeitet. Aber ich bin davon ausgegangen, wenn kein lost+found angelegt wird, dann wird es auch nicht benötigt. Wenn reiserfsck aber seinen Müll in lost+found ablegt, dann sollte es auch angelegt sein. Und das muß vorher geschehen sein, denn lost+found tritt ja erst in Aktion, wenn irgendwas nicht stimmt. Wenn da Dateien auftauchen, die nicht eindeutig als gelöscht gekennzeichnet sind, aber trotzdem in keinem Verzeichnis stehen, so sind sie irgendwie verloren im Dateisystem. Diese Dateien werden in lost+found abgelegt. Der Dateiname kann nicht mehr ermittelt werden, denn der steht im Verzeichnis. Wenn das System aber wüßte, welches Verzeichnis, dann legte es die Datei gleich dorthin und nicht nach lost+found. Auserdem kann unter Linux eine Datei auch mehere Namen haben, über Hardlinks. Wenn aber so ein lost+found nicht existiert, dann müßte es angelegt werden, wenn es gebraucht wird. Wenn aber das ganze Dateisystem kaputt ist, woher sollte Platz für das Verzeichnis geschaffen werden? Es müßte doch notfalls die Blöcke, die gerettet werden sollen überschrieben werden. Hier sehe ich allerdings auch eine Schwierigkeit für ReiserFS: Bei ext2 wird von vorneherein, beim anlegen, gesagt, wieviele I-Nodes benötigt werden. Soundsoviele Blöcke bleiben den I-Nodes vorbehalten, der Rest sind Datenblöcke, abgesehen von den Superblöcken, die schon vorher herausgerechnet sind. Damit ist die maximale Anzahl von I-Nodes auf diesem Dateisystem bekannt und somit auch die benötigte Größe von lost+found Bei ReiserFS ist es offensichtlich anders. Da werden die I-Nodes vermutlich dynamisch angelegt. Daher weiß man von vorneherein nicht, wie groß lost+found sein soll. Wenn aber so ein lost+found nicht existiert, dann müßte es angelegt werden, wenn es gebraucht wird. Wenn aber das ganze Dateisystem kaputt ist, woher sollte Platz für das Verzeichnis geschaffen werden? Es müßte doch notfalls die Blöcke, die gerettet werden sollen überschrieben werden. Hier sehe ich allerdings auch eine Schwierigkeit für ReiserFS: Bei ext2 wird von vorneherein, beim anlegen, gesagt, wieviele I-Nodes benötigt werden. Soundsoviele Blöcke bleiben den I-Nodes vorbehalten, der Rest sind Datenblöcke, abgesehen von den Superblöcken, die schon vorher herausgerechnet sind. Damit ist die maximale Anzahl von I-Nodes auf diesem Dateisystem bekannt und somit auch die benötigte Größe von lost+found Bei ReiserFS ist es offensichtlich anders. Da werden die I-Nodes vermutlich dynamisch angelegt. Daher weiß man von vorneherein nicht, wie groß lost+found sein soll. Vielleicht wird bei ReiserFS lost+found erst angelegt, wenn es benötigt wird, im Vertrauen darauf, daß sich irgendwo noch ein paar sicher unbelegte Blöcke finden lassen. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9

On Sam, 18 Jan 2003 at 08:05 (+0100), David Haller wrote:

Hallo,

On Sat, 18 Jan 2003, Bernd Brodesser wrote:

...

Wenn aber so ein lost+found nicht existiert, [..] sollen überschrieben werden.

Hier sehe ich allerdings auch eine Schwierigkeit für ReiserFS: Bei [..] auch die benötigte Größe von lost+found [..] Wenn aber so ein lost+found nicht existiert, [..] sollen überschrieben werden.

Hier sehe ich allerdings auch eine Schwierigkeit für ReiserFS: Bei [..] auch die benötigte Größe von lost+found

Bernd? Du wiederholst dich...

Du hast seinen Robot beim Schummeln erwischt ;-) Jan

Hartmut Meyer wrote:

...

Dieser Link http://marc.theaimsgroup.com/?l=reiserfs&m=102897202005397&w=2 wurde ja zuvor schon gepostet. Wenn es ist wie Du sagst, wie konnte "Z." dann wieder an seine Daten kommen?

Zitat aus der von dir genannten URL:

"I guess this only worked because immediatly unmounted the partition after my unfortunate error to prevent writing new nodes and data."

Man beachte vor allem "to prevent writing new nodes and data".

Das dürfte

1. riesen Glück gewesen sein und

ja, aber manchmal hat man nunmal glück.

2. auf Jörg nicht zutreffen.

warum nicht? micha

Hallo zusammen, ich wollte mich nochmals im nachhinein bedanken. Eure Links haben mir in meinere "Not" weitergeholfen und auf den richtigen Weg geführt. Bei meinem weiteren Suchen im Internet, bin auf folgenden Link gestossen: http://www.geocrawler.com/archives/3/3455/2001/4/0/5652135/ Nach der Ausführung des Befehls "reiserfsck --rebuild-tree -S -l rebuild.log /dev/hda5 dauerte es für meine 40GB Partition etwa 30Min., dann war ein neues Verzeichnis Namens "lost+found" da. In diesem Verz. sind jede Menge Dateien und Ordner unter anderem auch die von mir versehentlich gelöschten. Allerdings muss ich mir nun noch die Rosinen rauspicken. Danke Jörg

Andrea Verbowsky, Mittwoch, 15. Januar 2003 01:40:

da kannst Du mal wieder sehen, was manche Artikelbeiträge wert sind!

Ja, selbst mitdenken hat noch selten geschadet. In diesem Fall wäre es für mich folgende Überlegung gewesen: Ein rm -fr (oder was Jörg auch immer gemacht hat) dauert auch bei 40 GB-Platten bestenfalls ne Minute. Wie soll die Platte in einer Minute 40 GB geschrieben haben? Die Daten _müssen_ also noch da sein, Frage ist halt nur, wie man drankommt. Aber so ein Vorfall ist doch immer gut: 1) Jörg wird mehr auf Backups achten 2) Jörg (und vielleicht manch andere hier) kennt sich jetzt besser mit seinem System aus, und kann später vielleicht mal anderen helfen, die in derselben Situation stecken. Gruß. Andy -- Andreas Feile www.feile.net

Hi, 0n 03/01/18@23:25 Andreas Feile told me:

Soweit mein Beitrag für heute. Wenn noch jemand was genauer wissen will, dann raus mit der Sprache, die HDD liegt noch drin und will getestet werden ;)

Hast Du den rm Befehl im ersten Fall (wo was wiederhergestellt wurde) durchlaufen lassen oder unterbrochen? -- bye maik