Re: [Bug-ddrescue] Interpreting logfile of restore to get list of corrupted files

[Chris Witham]

On 27/09/06, Ariel <address@hidden> wrote:
> > The problem is that my failed partition is ReiserFS.  The icheck and
> > ncheck commands are part of debugfs, which is ext2/ext3-specific, and
> > all I can find online is other people complaining that ReiserFS
> > doesn't have an equivalent command.  There doesn't appear to be any
> > way to get ReiserFS to tell what files are on what sectors.
>
> You might want to email a list dedicated to ReiserFS.

I did get in touch with the ReiserFS list, and found out that the
icheck/ncheck commannds in debugfs are really a short interface to
brute-force checks, and that 'find <location> -type f -exec cat {}
> /dev/null \;' is no more stressful.  I ended up scanning all the
files on the disk with find, found 3 corrupted files, restored the
disk image, deleted those 3 files, re-ran LILO, and everything seems
to be fine from there.


> Be glad it's this type of failure, and not a total loss of the hard disk.
> BTW what model hard disk is this? Failures are inevitable, when a disk
> fails slowly like this it's a plus.

It is (was?) a Seagate drive, 120GB.  I don't have the drive handy to
check the full model number.


> You should copy your data, and reinstall the OS. If that's too much work,
> then at least refresh each file - meaning get the original, and copy it
> over the existing. (In debian it's easy, just apt-get --reinstall and a
> list of packages.)

Of the 3 files found, two were in the Firefox cache (and therefore
utterly unimportant) and the other was related to dpkg/apt.  An
"apt-get update" or perhaps re-install of apt or dpkg should fix that,
but I haven't been really been worried about fixing it just yet.


> One other options: if you are 100% done with recovering your data, and you
> don't need anything else on the old hard disk, then try to mount it, and
> then copy every single file to /dev/null - then watch where the errors
> are. But be careful - the kernel could crash if the fs is corrupted badly.
> Also if a directory entry is bad, you will not be able to check the files
> under it.

That is ultimately what identified the bad files.  Fortunately, the
drive was not yet so damaged to not be able to withstand that scan.

Thanks for the information and the support -- my system is functional
again with minimal data loss thanks to it.


Chris