On Thu, 2005-10-06 at 14:33 +0200, Andreas Engelbert wrote: > 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?
The offsets of these things are described in jfs_filsys.h. The superblocks are at 0x8000 & 0xf000. 0x1000 after the primary superblock is where the aggregate inode map starts (struct dinomap). The aggregate IAG begins at 0xA000, and the aggregate inode extent starts at 0xB000. ino 16 starts 0x2000 into the extent, so it starts at 0xD000 (not all 32 of the aggregate inodes are valid). You can use jfs_debugfs to find it by typing "in 16 a", which will show you that it begins at block 13. "iag 0 a" will show you the aggregate iag. > 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. I don't understand this statement. If IAG[0] starts at BLOCK 0xcc16, the control structure would be at block 0xcc15. The IAG wouldn't start at byte offset 0xcc16. > 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. The data of aggregate inode 16 is the data of the inode map (a control page followed by the IAGs). Therefore, the xads that describe the inode map are an xtree that has its root in aggregate inode 16. Of course, reformatting will cause this the root of the xtree to contain only iag 0. The other pages of the xtree are probably still on disk somewhere. > 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? I think the xad's start at 0xd00, but there can be as many as 18. See jfs_dinode.h & jfs_xtree.h. > 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? :) I don't think I promised that it would be easy. > Andreas. > -- David Kleikamp IBM Linux Technology Center ------------------------------------------------------- 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
