Lost+Found

Lost+Found

[Anders Widman]

   Hello again =)

   With the release of Kernel 2.4.19-8 I hoped that my damaged
   filesystem, that was repaired with the reiserfs tools a while ago
   could be used.

   The problem was that it wasn't possible to change anything in the
   lost+found folder. If I tried to move or rename a file/folder the
   kernel would crash and a dump was printed.

   Now, with kernel 2.4.19-8 It seems as at least some folders are
   movable. However, some aren't and some strange errors occur. I do
   not get any crashes, or not even a error in /var/log/messages. The
   errors are that all files suddenly vanish from lost+found and I
   have to reboot to be able to even fsck. If I do not reboot I can
   still access and read all other folders, except lost+found.

   What can be wrong?

   //Anders

Lost+found

[Jeffrey Sandel]

Recently I ran xfs_repair due to a firmware upgrade on an unmounted
disk. The repair recovered the data but moved it to the lost+found
directory.

How do I recover file names and ownership?

Thanks!

Jeffrey Sandel

Re: Lost+found

[Barry Naujok]

On Tue, 08 Apr 2008 15:20:33 +1000, Jeffrey Sandel  
<webmaster@javainbaja.com> wrote:

> Recently I ran xfs_repair due to a firmware upgrade on an unmounted
> disk. The repair recovered the data but moved it to the lost+found
> directory.
>
> How do I recover file names and ownership?

The only real options you have AFAIK is the file command to try and  
identify
what type of file it is and just manually inspecting the files.

Then, you might be able to derive its filename and where it came from.

Regards,
Barry.

Re: Lost+found

[Justin Piszcz]

On Wed, 9 Apr 2008, Barry Naujok wrote:

> On Tue, 08 Apr 2008 15:20:33 +1000, Jeffrey Sandel <webmaster@javainbaja.com> 
> wrote:
>
>> Recently I ran xfs_repair due to a firmware upgrade on an unmounted
>> disk. The repair recovered the data but moved it to the lost+found
>> directory.
>> 
>> How do I recover file names and ownership?
>
> The only real options you have AFAIK is the file command to try and identify
> what type of file it is and just manually inspecting the files.
>
> Then, you might be able to derive its filename and where it came from.
>
> Regards,
> Barry.
>

Is there any chance this process could ever be improved so that the files 
are restored back to their original locations or there is something that 
keeps track of where they were located?

Justin.

Re: Lost+found

[Eric Sandeen]

Justin Piszcz wrote:
> 
> On Wed, 9 Apr 2008, Barry Naujok wrote:
> 
>> On Tue, 08 Apr 2008 15:20:33 +1000, Jeffrey Sandel <webmaster@javainbaja.com> 
>> wrote:
>>
>>> Recently I ran xfs_repair due to a firmware upgrade on an unmounted
>>> disk. The repair recovered the data but moved it to the lost+found
>>> directory.
>>>
>>> How do I recover file names and ownership?
>> The only real options you have AFAIK is the file command to try and identify
>> what type of file it is and just manually inspecting the files.
>>
>> Then, you might be able to derive its filename and where it came from.
>>
>> Regards,
>> Barry.
>>
> 
> Is there any chance this process could ever be improved so that the files 
> are restored back to their original locations or there is something that 
> keeps track of where they were located?

The whole reason they're in lost+found is because they are "orphaned" -
allocated & in use but not referenced by any directory... so the best
xfs_repair can do is rename to lost+found with the inode number.

Crosses my mind that one could probably write a generic tool which could
work with a package manager db to check file md5sums in /lost+found, if
the files happen to be system files installed via a package.... but if
they're files from your homedir or whatnot, it's tougher.

-Eric

Re: Lost+found

[Christoph Hellwig]

On Wed, Apr 09, 2008 at 08:11:13AM -0500, Eric Sandeen wrote:
> The whole reason they're in lost+found is because they are "orphaned" -
> allocated & in use but not referenced by any directory... so the best
> xfs_repair can do is rename to lost+found with the inode number.

At least until we get parent pointers.  Niv, any updates?

Re: Lost+found

[Emmanuel Florac]

Le Wed, 09 Apr 2008 08:11:13 -0500
Eric Sandeen <sandeen@sandeen.net> écrivait:

> Crosses my mind that one could probably write a generic tool which
> could work with a package manager db to check file md5sums
> in /lost+found, if the files happen to be system files installed via
> a package....

Yup, I've done something similar when I used a PC with a bugged via
chipset which regularly broke apart filesystems under heavy load... I
used a tool named afick to index the whole disks (it stores md5 of
everything in a small db) and with some tinkering I was able to restore
everything from lost+found each time some filesystem went belly up
(once a month...)

-- 
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

Re: Lost+found

[Niv Sardi]

Christoph Hellwig <hch@infradead.org> writes:
> On Wed, Apr 09, 2008 at 08:11:13AM -0500, Eric Sandeen wrote:
>> The whole reason they're in lost+found is because they are "orphaned" -
>> allocated & in use but not referenced by any directory... so the best
>> xfs_repair can do is rename to lost+found with the inode number.
>
> At least until we get parent pointers.  Niv, any updates?

I was lost in DMAPI land for a while, I'll resume work on PP next week,
patches up for review soonish after I fix some issues.

Cheers,
-- 
Niv Sardi