Greetings!

All the special JFS-structures as superblocks, freeblock maps, inode
maps, reserved inodes on a 1.6 TB partition are overwritten by mkfs.ext2.

Most of the inodes are probably untouched, because JFS dynamicly
allocates inodes at unused blocks, right? But they are cut off from the
B-Tree.

I thought it might be a rather easy task to investigate each aggregate
block and guess, if the data casted into the jfs_dinode is plausible.
For example skip inode candidates with timestamps in the future and so
on. After this time consuming investigation, the maping of inode numbers
to blocks could be rebuild. It should also be possible to crawl through
the discoverd nodes and mark their used blocks.

So we end up with a lot cut-off subtrees. Next task is to find the root
of each subtree and to join them in a recreated global fileset-root.
With everything else rebuild like a mkjfs would have done.

Have I forgott something or got it completly wrong? I've done a little
coding but more java then c and dont feel competend for that task. But a
filesystem guru here would probably have made such a tool, if possible.
Is there a way to automate jfs_debug and do the nessesary steps with it?

For me, its not so much the lost data as the challenge to get it back
together and maybe learn a bit about the filesystem im using. But
down-to-earth, its a bit to hard for me, so i'm gratful for every help.

(please excuse my bad english)



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion

Reply via email to