On Tue, 2007-07-24 at 19:11 -0700, Taran Lewis wrote: > Well, I'm back. > > Here's what has happened since we last spoke. I got a new HD big > enough to make an image file. I dd'ed to make the image. (what's the > difference between dd and dd_rhelp?) > . > I used losetup to make my loop device and then ran fsck.jfs -vf > on /dev/loop0. Unfortunately, there were some errors. > > The first time I ran it I had a giant string of this message and this > final exit code. I forgot to output to a text file the first time so > I've lost the beginning of the message. It ended like this. > > The extent descriptor for inodes 494753248 through 494753279 is invalid. > (Inode Allocation Map A16, Inode Allocation Group -1996367915, Extent Index > 47). > etc etc etc etc > The extent descriptor for inodes 494755808 through 494755839 is invalid. > (Inode Allocation Map A16, Inode Allocation Group -1996367915, Extent Index > 127). > cannot recover files and/or directories 494755808 through 494755839. Will > release. > processing terminated: 7/24/2007 17:48:20 with return code: 10053 exit > code: 8.
Something's messed up big-time. The Inode Allocation Group should never be bigger than 128 (or negative). > Try number two and those subsequent got me this: > > /sbin/fsck.jfs version 1.1.10, 19-Oct-2005 > processing started: 7/24/2007 17.49.29 > The current device is: /dev/loop0 > Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 > Primary superblock is valid. > The type of file system for the device is JFS. > Block size in bytes: 4096 > Filesystem size in blocks: 122097920 > **Phase 0 - Replay Journal Log > LOGREDO: Log already redone! > logredo returned rc = 0 > **Phase 1 - Check Blocks, Files/Directories, and Directory Entries > Duplicate reference to 4 block(s) beginning at offset 7187876 found in file > system object IA16. > etc etc etc etc > Duplicate reference to 4 block(s) beginning at offset 36768276 found in file > system object IA16. > Inode A16 has references to cross linked blocks. > processing terminated: 7/24/2007 17:49:30 with return code: 10053 exit > code: 8. It looks pretty messed up. I'm assuming that 'etc etc etc' implies there are a lot of these. Even if I could patch fsck to try to recover as much as possible and continue here, I doubt that it would get very much further. > I can post the full output if needed. I don't think it would be helpful. > Right now, I am running jfsrec on the image file to see what it is > able to come up with. Let's hope that works for you. > Is there anything else to try with fsck? I saw in the man entry that > the -o option is to be used as a last resort. I guess with an image > file I don't have anything to lose (except the 42 hours it would take > to make a new one). You must be referring to the --omit_journal_replay option. That only helps if jfs_fsck is unable to replay the journal. It won't help in your case. > > I saw a post > (http://osdir.com/ml/file-systems.jfs.general/2005-06/msg00017.html) > that mentioned trying a later version of jfsutils. I'm using the one > in the Fedora C6 repository: jfsutils-1.1.10-4.1 My subversion > compiling of jfsrec was successful (first time I've ever done that) so > I could have a stab at installing a more up to date version of > jfsutils. You can try, but I don't know of any fixes since 1.1.10 that would help you. It seems the partition is damaged beyond the point that jfs_fsck can recover it. > > Thank you again for all of your help. -- David Kleikamp IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
