Thread: [Jfs-discussion] Help: jfs_fsck Segfaults on failed drive
Brought to you by:
blaschke-oss,
shaggyk
From: Paul L. <pau...@ea...> - 2004-07-21 07:00:00
|
I had a failure on my JFS drive that was preventing my Linux machine from booting. I booted up knoppix and ran fsck on it. It seemed to work and I was able to mount the drive under knoppix. However, on reboot, the drive still failed to load properly. So back into Knoppix and another try at fsck. This time I get a Segfault. I played a little with jfs_debugfs but I don't know how to do much other than look around. Below is the output of jfs_fsck. I also tried version 1.1.6 and got the same output and Segfault. I also appended some outputs from jfs_debugfs. Anyone have an idea how to get this drive working again? At least enough to get some files off before I reformat it? Thanks, Paul Lanier root@tty1[knoppix]# jfs_fsck /dev/hda6 jfs_fsck version 1.1.4, 30-Oct-2003 processing started: 7/20/2004 15.36.5 Using default parameter: -p The current device is: /dev/hda6 Block size in bytes: 4096 Filesystem size in blocks: 4640564 **Phase 0 - Replay Journal Log Segmentation Fault root@tty1[knoppix]# jfs_fsck -n /dev/hda6 jfs_fsck version 1.1.4, 30-Oct-2003 processing started: 7/20/2004 15.36.5 The current device is: /dev/hda6 Block size in bytes: 4096 Filesystem size in blocks: 4640564 **Phase 1 - Check Blocks, Files/Directories, and Directory Entries cannot repair an allocation error for files and/or directories -1757994816 through -1757994785. Segmentation Fault jfs_debugfs version 1.1.6, 28-Apr-2004 Aggregate Block Size: 4096 >su p [1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00 [2] s_version: 1 [16] s_ait2.addr2: 0x0000024d [3] s_size: 0x0000000002357398 s_ait2.address: 589 [4] s_bsize: 4096 [17] s_logdev: 0x00000306 [5] s_l2bsize: 12 [18] s_logserial: 0x00000009 [6] s_l2bfactor: 3 [19] s_logpxd.len: 8192 [7] s_pbsize: 512 [20] s_logpxd.addr1: 0x00 [8] s_l2pbsize: 9 [21] s_logpxd.addr2: 0x0046af34 [9] pad: Not Displayed s_logpxd.address: 4632372 [10] s_agsize: 0x00010000 [22] s_fsckpxd.len: 193 [11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00 JFS_LINUX [24] s_fsckpxd.addr2: 0x0046ae73 JFS_COMMIT JFS_GROUPCOMMIT s_fsckpxd.address: 4632179 JFS_INLINELOG [25] s_time.tv_sec: 0x40ca0ad7 [26] s_time.tv_nsec: 0x00000000 [27] s_fpack: '' [12] s_state: 0x00000001 FM_MOUNT [13] s_compress: 0 [14] s_ait2.len: 4 display_super: [m]odify or e[x]it: >su s [1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00 [2] s_version: 1 [16] s_ait2.addr2: 0x0000024d [3] s_size: 0x0000000002357398 s_ait2.address: 589 [4] s_bsize: 4096 [17] s_logdev: 0x00000306 [5] s_l2bsize: 12 [18] s_logserial: 0x00000008 [6] s_l2bfactor: 3 [19] s_logpxd.len: 8192 [7] s_pbsize: 512 [20] s_logpxd.addr1: 0x00 [8] s_l2pbsize: 9 [21] s_logpxd.addr2: 0x0046af34 [9] pad: Not Displayed s_logpxd.address: 4632372 [10] s_agsize: 0x00010000 [22] s_fsckpxd.len: 193 [11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00 JFS_LINUX [24] s_fsckpxd.addr2: 0x0046ae73 JFS_COMMIT JFS_GROUPCOMMIT s_fsckpxd.address: 4632179 JFS_INLINELOG [25] s_time.tv_sec: 0x40ca0ad7 [26] s_time.tv_nsec: 0x00000000 [27] s_fpack: '' [12] s_state: 0x00000000 FM_CLEAN [13] s_compress: 0 [14] s_ait2.len: 4 display_super: [m]odify or e[x]it: > s2p p [1] s_magic: 'JFS1' [16] s_aim2.len: 2 [2] s_version: 1 [17] s_aim2.addr1: 0x00 [3] s_size: 0x0000000002357398 [18] s_aim2.addr2: 0x0000024b [4] s_bsize: 4096 s_aim2.address: 587 [5] s_l2bsize: 12 [19] s_logdev: 0x00000306 [6] s_l2bfactor: 3 [20] s_logserial: 0x00000009 [7] s_pbsize: 512 [21] s_logpxd.len: 8192 [8] s_l2pbsize: 9 [22] s_logpxd.addr1: 0x00 [9] s_agsize: 0x00010000 [23] s_logpxd.addr2: 0x0046af34 [10] s_flag: 0x10200900 s_logpxd.address: 4632372 LINUX [24] s_fsckpxd.len: 193 GROUPCOMMIT [25] s_fsckpxd.addr1: 0x00 INLINELOG [26] s_fsckpxd.addr2: 0x0046ae73 s_fsckpxd.address: 4632179 [11] s_state: 0x00000001 [27] s_fsckloglen: 50 MOUNT [28] s_fscklog: 2 [12] s_compress: 0 [29] s_fpack: ' ' [13] s_ait2.len: 4 [14] s_ait2.addr1: 0x00 [15] s_ait2.addr2: 0x0000024d s_ait2.address: 589 display_super2: [m]odify or e[x]it: >s2p s [1] s_magic: 'JFS1' [16] s_aim2.len: 2 [2] s_version: 1 [17] s_aim2.addr1: 0x00 [3] s_size: 0x0000000002357398 [18] s_aim2.addr2: 0x0000024b [4] s_bsize: 4096 s_aim2.address: 587 [5] s_l2bsize: 12 [19] s_logdev: 0x00000306 [6] s_l2bfactor: 3 [20] s_logserial: 0x00000008 [7] s_pbsize: 512 [21] s_logpxd.len: 8192 [8] s_l2pbsize: 9 [22] s_logpxd.addr1: 0x00 [9] s_agsize: 0x00010000 [23] s_logpxd.addr2: 0x0046af34 [10] s_flag: 0x10200900 s_logpxd.address: 4632372 LINUX [24] s_fsckpxd.len: 193 GROUPCOMMIT [25] s_fsckpxd.addr1: 0x00 INLINELOG [26] s_fsckpxd.addr2: 0x0046ae73 s_fsckpxd.address: 4632179 [11] s_state: 0x00000000 [27] s_fsckloglen: 50 CLEAN [28] s_fscklog: 2 [12] s_compress: 0 [29] s_fpack: ' ' [13] s_ait2.len: 4 [14] s_ait2.addr1: 0x00 [15] s_ait2.addr2: 0x0000024d s_ait2.address: 589 display_super2: [m]odify or e[x]it: > i 2 Inode 2 at block 593, offset 0x400: [1] di_inostamp: 0x40ca0361 [19] di_mtime.tv_nsec: 0x0681ed10 [2] di_fileset: 16 [20] di_otime.tv_sec: 0x40ca0361 [3] di_number: 2 [21] di_otime.tv_nsec: 0x00000000 [4] di_gen: 1 [22] di_acl.flag: 0x00 [5] di_ixpxd.len: 4 [23] di_acl.rsrvd: Not Displayed [6] di_ixpxd.addr1: 0x00 [24] di_acl.size: 0x00000000 [7] di_ixpxd.addr2: 0x00000251 [25] di_acl.len: 0 di_ixpxd.address: 593 [26] di_acl.addr1: 0x00 [8] di_size: 0x0000000000001000 [27] di_acl.addr2: 0x00000000 [9] di_nblocks: 0x0000000000000002 di_acl.address: 0 [10] di_nlink: 23 [28] di_ea.flag: 0x00 [11] di_uid: 0 [29] di_ea.rsrvd: Not Displayed [12] di_gid: 0 [30] di_ea.size: 0x00000000 [13] di_mode: 0x000141ed [31] di_ea.len: 0 0040755 drwx [32] di_ea.addr1: 0x00 [14] di_atime.tv_sec: 0x40fa5548 [33] di_ea.addr2: 0x00000000 [15] di_atime.tv_nsec: 0x26b2bd30 di_ea.address: 0 [16] di_ctime.tv_sec: 0x40fa5549 [34] di_next_index: 32 [17] di_ctime.tv_nsec: 0x0681ed10 [35] di_acltype: 0x00000000 [18] di_mtime.tv_sec: 0x40fa5549 change_inode: [m]odify or e[x]it > dir 2 idotdot = 2 8223 bin 4096 boot 4 cdrom 233568 cdrom0 8225 dev 233507 empress 4128 etc 8228 home 55232 initrd 5 initrd.img 8229 lib 4160 media 8230 mnt 55136 opt 8231 proc 8232 root 233508 samba 8233 sbin 55104 srv 24719 sys 8234 tmp 8192 usr 4099 var 6 vmlinuz > dm Block allocation map control page at block 16 [1] dn_mapsize: 0x0000046ae73 [9] dn_agheigth: 1 [2] dn_nfree: 0x00000438fdc [10] dn_agwidth: 2 [3] dn_l2nbperpage: 0 [11] dn_agstart: 85 [4] dn_numag: 71 [12] dn_agl2size: 16 [5] dn_maxlevel: 0 [13] dn_agfree: type 'f' [6] dn_maxag: 69 [14] dn_agsize: 65536 [7] dn_agpref: 57 [15] pad: Not Displayed [8] dn_aglevel: 0 display_dbmap: [m]odify, [f]ree count, [t]ree, e[x]it > |
From: Dave K. <sh...@au...> - 2004-07-21 22:49:51
Attachments:
fsck_msgs.patch
|
On Tue, 2004-07-20 at 23:00, Paul Lanier wrote: > I had a failure on my JFS drive that was preventing my Linux machine > from booting. I booted up knoppix and ran fsck on it. It seemed to > work and I was able to mount the drive under knoppix. However, on > reboot, the drive still failed to load properly. So back into Knoppix > and another try at fsck. This time I get a Segfault. I played a little > with jfs_debugfs but I don't know how to do much other than look > around. Below is the output of jfs_fsck. I also tried version 1.1.6 > and got the same output and Segfault. Is this the 1.1.6 segfault in phase 0, or in phase 1? I have a patch that may fix the segfault in phase 1. It should apply to jfsutils 1.1.6. The patch fixes a problem with a bad format specifier, and I went ahead and fixed a lot of messages so that inode numbers don't show up as negative. (They are unsigned.) If the phase 0 segfault still occurs in 1.1.6, could you maybe get a stack trace by running fsck.jfs from gdb? > I also appended some outputs from > jfs_debugfs. Anyone have an idea how to get this drive working again? > At least enough to get some files off before I reformat it? I'm not sure how badly the file system is damaged. Usually you can mount read-only to recover data, but it sounds like you may have some pretty serious problems if you can't boot. -- David Kleikamp IBM Linux Technology Center |
From: Paul L. <pau...@ea...> - 2004-07-22 05:38:37
Attachments:
gdb.log
|
I had both segfaults. The patch fixed the Phase 1 segfault but not the Phase 0 problem. I've attached a gdb log with a stack backtrace. Let me know if that's not what you wanted. I tried to compile jfsutils with debug info but that stack trace still doesn't look very useful so maybe I didn't set it up right. I was able to mount the drive in readonly mode (didn't think to try that before). I think I'll just get what I need off and re-format it. Let me know if you want another trace before I get rid of it. -Paul Dave Kleikamp wrote: >On Tue, 2004-07-20 at 23:00, Paul Lanier wrote: > > >>I had a failure on my JFS drive that was preventing my Linux machine >>from booting. I booted up knoppix and ran fsck on it. It seemed to >>work and I was able to mount the drive under knoppix. However, on >>reboot, the drive still failed to load properly. So back into Knoppix >>and another try at fsck. This time I get a Segfault. I played a little >>with jfs_debugfs but I don't know how to do much other than look >>around. Below is the output of jfs_fsck. I also tried version 1.1.6 >>and got the same output and Segfault. >> >> > >Is this the 1.1.6 segfault in phase 0, or in phase 1? I have a patch >that may fix the segfault in phase 1. It should apply to jfsutils >1.1.6. The patch fixes a problem with a bad format specifier, and I >went ahead and fixed a lot of messages so that inode numbers don't show >up as negative. (They are unsigned.) > >If the phase 0 segfault still occurs in 1.1.6, could you maybe get a >stack trace by running fsck.jfs from gdb? > > > >> I also appended some outputs from >>jfs_debugfs. Anyone have an idea how to get this drive working again? >>At least enough to get some files off before I reformat it? >> >> > >I'm not sure how badly the file system is damaged. Usually you can >mount read-only to recover data, but it sounds like you may have some >pretty serious problems if you can't boot. > > > |
From: Dave K. <sh...@au...> - 2004-07-22 15:57:13
|
On Wed, 2004-07-21 at 21:39, Paul Lanier wrote: > I had both segfaults. The patch fixed the Phase 1 segfault but not the > Phase 0 problem. I've attached a gdb log with a stack backtrace. Let > me know if that's not what you wanted. I tried to compile jfsutils with > debug info but that stack trace still doesn't look very useful so maybe > I didn't set it up right. That's what I wanted, but it's not very helpful. I'm afraid I don't have a lot of time to try to get this debugged. I'm about to leave on a two-week vacation. > I was able to mount the drive in readonly mode (didn't think to try that > before). I think I'll just get what I need off and re-format it. Let > me know if you want another trace before I get rid of it. After recovering what you can, you can try to run "fsck.jfs --omit_journal_replay". This will try to fix everything up without replaying the journal. This may potentially cause a lot of files and directories to be tossed out, so it's a good idea to recover anything important first. -- David Kleikamp IBM Linux Technology Center |