Hello!

Surprisingly enough, my old dying jfs volume is still holds out. But
its getting time for the final approach :)

Here's what I got. Discovered 587424 pretty inodes wich spread over 240
IAGs. In a test, I reintroduced ino 33-36 to the IAG[0] by adding those
addreses to pxd_t and changing the di_inostamp to the actual value.
After that, fsck did fully accept those lost souls and linked them to
lost+found.

The problem for me is, how to allocate the next 239 IAGs. I tried to
find the Aggregate_Inode[16] wich should describe the Fileset Inode Map,
but couldnt get there:

[ATTEMPT]

Found the 'JFS1' magic string of the superblock at 0x8000 and 0xF000.
0x1000 after the primary one, the first aggregate ino extent starts. 16
inos to skipp means offset 0x2000. So the ino-16 should be at 0xB000 or
0x12000, right?

0000b000:  00200000 00200000 00209E07 00000000   |. ... ... ......|
0000b010:  00010000 08000000 55000000 04000000   |........U.......|
0000b020:  050D0DFF FFFF0DFF FFFFFFFF FFFFFFFF   |................|
........:  lots of  FFFFFFFF    and   00000000
[...]
00012000:  00200000 00200000 00009F07 00000000   |. ... ..........|
00012010:  00010000 08000000 55000000 04000000   |........U.......|
00012020:  050D0DFF FFFF0DFF FFFFFFFF FFFFFFFF   |................|
........:  the same

IAG[0] is located at 0xCC16, so the 4k controll structure would be at
0xBC16, but the bytes above don't contain even a close address.

The only grep on 0000BC16 was at block 15375:
03c0f000:  00200000 00200000 0000BC16 00000000
But this addr interpreted as an inode, seems not right
(the same with 0xCC16)

> d 15375 0 i
Block: 15375     Real Address 0x3c0f000
[1] di_inostamp:        0x00002000
[2] di_fileset:         8192
[3] di_number:          125673472
[5] di_ixpxd.len:       256
[8] di_size:    0x0000000400000055
[9] di_nblocks: 0xff0dffffff0d0d05
[10] di_nlink:          -1

[/ATTEMPT]

So i stuck here. Please give me a guided tour to the bytes wich
determine the pos and size of the filesets InodeAllocationMap. I thought
there is a xad struct, describing the map. That could be pointed to
where its save to overwrite 241 blocks. You told me allready about a
'NextIAG' field in the controll structure logically at IAG[-1], wich
then has to point to 240, i think. If the JFS accepts, that there are
240 allocated IAGs, the rest is straightforward.

By the way... At wich offset start the 8 inline xad's, inside an inode?
This would be helpful for plan B, wich is to lowlevel copy the files to
another volume. (i have the md5-hashes for the most important files, so
identification without directory traverse is no problem)

Dave Kleikamp wrote:

> I'm sure you'll run into something.  Hopefully, the problems won't be
> too difficult to overcome.
> 

Thank you again for your help. This is not really too difficult, right? :)

Andreas.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion

Reply via email to