I have not given in yet. :) The scann turned out to take a while. Tomorrow I should have a list of presumably 16000 ino extents. But thats only the easy part.
Dave Kleikamp wrote: >>Do you say that, if the apropriate tables point to all the discovered >>ino's, then the recovery of a sane and complete tree is just done by a >>fsck run? cool! Well, I almost forgot the mapping of the allocated and >>the free blocks. > > > Hmm. You would have to build the iag's correctly so that they point to > the discovered inode extents, and the imap inode would have to be > created such that the data of the file (aggregate inode 16) is the iags > (and they have to be at the right logical offset). If this is done > right, then fsck may be able to fix everything else. It normally > rebuilds the blocks maps completely, so you shouldn't have to worry > about that. > You point me to agg ino 16, wich is the "filedescriptor" for the IAG pages of the first fileset. So I dont have to touch the aggregate inode table/map and neither the secondary structures? I did investigate a bit in the jfs layout paper, but wasnt able to get it all into my head. Here is my clouded plan: Agg ino 16 modification. A contiguous imap makes for a simple B+tree with just one xad struct: off=0; len=entire [in blocks]; addr=block number of the imap. But how are the 40 bits of addr split into addr1 and addr2? /*inode allocation group page Now the imap. The steps for finding a inode in the Imap start with iag key = (inum / 4096) * 4096 + 4096. There is a offset of one page. Im not sure what has to be done with the first 4k. I go for a contiguous strip of enough IAG pages to span till the largest found inode number. The agstart and iagnum problem. Should I forget about the 102 AGs on my aggregate? Probably the old inods are alligned to the same AG-partitioning. Would a incorrect iagnum in the IAG struct cause any problems for reading access? The only thing I understand about the fwd and back pointers, is that they are recreated by fsck. But the rest is pretty much clear to me. Just set all bits to not-allocated and then switch them for every inode in the list, wich has at least one link. And of course set the pxd_t to the inode extent addresses. Assumed, I get this far and hand over to fsck for final clearance. I hope its routines are not too quick in dumping inconsistant inodes. But if so, that would only result in overwriting something like nlink and inostamp, and should be reversible once the inos have been found, right? Im getting more optimistic now. It seems that the really difficult stuff like traversing all the directory trees are not necessary. But there are probably more problems ahead. Andreas ------------------------------------------------------- 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
