On Wed, 2005-08-17 at 22:55 +0200, Simon Hoerder wrote: > [...] > > Very odd. I don't know what would scramble a single 4-byte value and > > leave everything else alone. > [...] > > > > Doesn't look good. :-( I think more than just the s_magic field got > > corrupted. > > > > I'm learning to use jfs_debugfs right now and it seems that parts of the > directory trees (the b-trees, if I've got it right), the iag maps and some > of the data have been scrambled too. I'm searching for my most important > files right now and try to recover them using dd. > > As far as I know, there was no disc access in progress when the power > failure occured. But it seems that I've got an even distribution of errors > all over the disks. (Raid duplicated it onto the other disc one-on-one. > That worked too well. ;-) ) As far as I've seen, it seems quite random. I > can't give any percentages right now.
I have no explanation of what could have caused this. :-( > > [...] > > > > Looks sane. s_state is FM_MOUNT, so jfs will not allow a read-write > > mount until the journal has been replayed by fsck. > [...] > > I found the post you were referring to. It dealt with AIX's jfs, which > > is completely different. > > Sorry for not linking it in the E-Mail. I completely forgot it. No problem. I found it easily. > I tried mounting it read-only but it quitted with the usual 'bad > superblock' message. > > All the files I've found so far, look sane. But some of them happen to > have more or less fatal errors in it. I cannot give any percentage of the > extent right now. (It's my private file server and there are only evenings > left for working on it.) > > Do you think, jfsutils 1.1.8 will help more than 1.1.7? Are there any > known pitfalls if I upgrade jfsutils without upgrading the fs? As far as > I've figuered out, there shouldn't be any. No. There are no dependencies between versions of the utilities and the kernels. I'm aware of no regressions in 1.1.8, so I do recommend upgrading, although I doubt it will help in this case. > I guess, my best way to recover anything is doing it manually. Do you have > any trick how I can get a lisitng of the directory contents, if the inode > of the directory can't be read? (That's the case for one of the rather > important directories. I've already found two subdirectories, but the main > directory would be just too sweet.) Ouch. You really need to get to the dtree that's anchored in the inode. I don't know how you'd find it without being able to see the inode. To find subdirectories, you may be able to write some extention to jfs_debugfs that tries to read every inode number (might be faster than a script), and if a directory is found, look at the parent inum to see if it is the lost inode. This would not work for regular files, and you wouldn't know the name of the directory even then. > I might even turn it into a little scripting exercise. If anything > reusable should turn out, I'll let you know. Thanks. Shaggy -- David Kleikamp IBM Linux Technology Center ------------------------------------------------------- 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
