On Thu, 2005-02-03 at 11:37 -0500, Guerra, Jim wrote:
> Shaggy -
>
> we just had a system crash with the following kernel messages
>
>
> Feb 2 15:40:26 va008 kernel: c016337b
> Feb 2 15:40:26 va008 kernel: PREEMPT SMP
> Feb 2 15:40:26 va008 kernel: Modules linked in: dm_mod
> Feb 2 15:40:26 va008 kernel: CPU: 3
> Feb 2 15:40:26 va008 kernel: EIP: 0060:[bd_forget+43/96] Not tainted
> VLI
> Feb 2 15:40:26 va008 kernel: EIP: 0060:[<c016337b>] Not tainted VLI
> Feb 2 15:40:26 va008 kernel: EFLAGS: 00010206 (2.6.10)
> Feb 2 15:40:26 va008 kernel: EIP is at bd_forget+0x2b/0x60
I haven't seen a crash like this before. I'm guessing that maybe
inode->i_devices might have gotten corrupted, but I don't know for sure.
bd_forget doesn't do too much.
> after we rebooted fsck.jfs came back with
>
>
> fsck.jfs version 1.1.7, 22-Jul-2004
> processing started: 2/3/2005 11.20.38
> The current device is: /dev/vg00/lv00
> 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: 731791360
> **Phase 0 - Replay Journal Log
> LOGREDO: Log already redone!
> logredo returned rc = 0
> **Phase 1 - Check Blocks, Files/Directories, and Directory Entries
> Primary metadata inode A16 is corrupt.
> Errors detected in the Primary File/Directory Allocation Table.
> Duplicate reference to 4 block(s) beginning at offset 3876468 found in file
> system object IA16.
> Inode A16 has references to cross linked blocks.
> Multiple metadata references to 4 blocks beginning at offset 3876468 have
> been detected.
> Duplicate block references have been detected in Metadata. CANNOT CONTINUE.
> Filesystem is dirty.
> processing terminated: 2/3/2005 11:24:13 with return code: 0 exit code:
> 4.
>
>
> how can I fix the problem ?
This one's pretty ugly. I'm not sure how this could have happened, but
this little patch might be able to salvage the partition.
This is a special case to fix this specific partition. After running
the patched version of jfs_fsck, throw it away. It will always
invalidate an inode extent beginning at block 3876468.
I once sent a similar patch to someone, but I never heard back whether
or not it worked. :^(
If it helps, maybe I can do something to make fsck do this kind of thing
automatically.
Good Luck,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
diff -urp jfsutils-1.1.7/fsck/fsckwsp.c jfsutils-jguerra/fsck/fsckwsp.c
--- jfsutils-1.1.7/fsck/fsckwsp.c 2004-04-28 13:58:42.000000000 -0500
+++ jfsutils-jguerra/fsck/fsckwsp.c 2005-02-03 12:57:15.000000000 -0600
@@ -3157,6 +3157,17 @@ int process_extent(struct fsck_inode_rec
? agg_recptr->highest_valid_fset_datablk : extent_addr +
extent_length - 1;
+ /*
+ * Special case to fix jguerra's file system
+ */
+ if (extent_addr == 3876468) {
+ *adjusted_length = 0;
+ *extent_is_valid = 0;
+ agg_recptr->corrections_needed = 1;
+
+ return FSCK_OK;
+ }
+
if (((first_valid > agg_recptr->highest_valid_fset_datablk)
&& (inorecptr->inode_type != metadata_inode)) ||
/*
