Re: [Jfs-discussion] fsck.jfs exit code 8

[Dave K. <sh...@li...>]

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