On Sun, 2006-10-08 at 19:23 +0200, luni@... wrote:
> A while ago I accidentally mke2fs:ed my root volume. Long story short - I
> blame the fact that the device numbering differed between my gentoo
> installation and the ubuntu live cd. I had backups on the most important
> data. However not on the newest digital photos and some other stuff.
> I have not found any good recovery tools aimed at jfs. I did run
> magicrescue and PhotoRec. Both looks for potential file starts and ends
> and extracts the data in between. This works ok on some filesystems and on
> volumes with low fragmentation. I did extract a few hundred thousand
> possible images, and the ones that I were interested in had random
> corruption or parts of the images were shuffeled around.
> I guess that this depends on fragmentation so that the files were not
> allocated in one large continous extent. After browsing the archives of
> this mailing list I got the idea that it might be possible to scan for
> inodes with a simple sanity check. I found this thread quite interesting:
> I am currently reading up on JFS (trying to understand the 'layout'-paper)
> and studying the source code. It seems like there is a lot of usable
> functions in jfs_debugfs.
> My idea is a program that does a read-only extraction of files from a
> trashed JFS filesystem (on disk or image). As there may be random errors
> on the volume one have to take into account that the metadata read from
> the device may be wrong.
> My approach is to scan the volume for sane inodes, and then try to write
> its extents to a file on an other (mounted) device. If the filename is
> extractable then use it, else use a file serial number (like
> dinode.di_number). It sounds quite simple but I guess its not. Is it a
> feasable approach? I will gladly spend some time to (try to) implement
> this. Any advice/ideas/help is greatly appriciated!
Finding the file data may be about that easy. Finding the file name
would require parsing the directory inodes. This is doable, but would
probably double the amount of work you'd need to do.
I think the thread you found should contain the information you need to
identify a group of inodes. If you have any questions, direct them my
IBM Linux Technology Center