I have a collection of drives that hold some 2TB of video, no LVM or RAID to increase the complexity/risk of complete data loss. These drives have jfs on the raw device, i.e. /dev/sda
They have successfully migrated through a progression of distributions: Fedora 7; Ubutnu 7; Gentoo; and now I'm going to tinker with Fedora 8. While Fedora 8 was installing and the jfs file systems were inactive I took a moment to modify the volume labels of three such file systems to give them more useful names. This change in the volume labels is the only action I took on them from the time the Gentoo system was retired and the Fedora 8 system was brought up. Two of the file systems are fine, but the third fails fsck like so: # jfs_fsck -nv /dev/sdd jfs_fsck version 1.1.12, 24-Aug-2007 processing started: 11/23/2007 12.25.44 The current device is: /dev/sdd Open(...READONLY...) returned rc = 0 Incorrect jlog length detected in the superblock (P). Incorrect jlog length detected in the superblock (S). Superblock is corrupt and cannot be repaired since both primary and secondary copies are corrupt. The only discussion that came close to addressing this was "fixing a jfs file system after getting stomped on by mdadm raid1" <http://sourceforge.net/mailarchive/message.php?msg_id=1117835850.24374.14.camel%40localhost> more than two years ago. I tinkered with the log length to no avail. I'll paste the Super Block listing from jfs_debug here. The only things that stand out are s_logdev and s_logserial which differ from the primary and secondary SB. I looked at one of the healthy file systems and those fields are identical in the primary and secondary super blocks. There was another discussion that sugessted creating a sparse file of the same size as the broken file system, running jfs_mkfs, and copying the super blocks. How dangerous would that be: Since these file systems are mounted read only 99% of the time I don't believe the directory structures will have been compromised. Is there a way to make jfs_fsck not look for a log file at all? I tried --omit_journal_replay, but it still complains that the log length is wrong. Thanks, Perry The jfs_debug super block listings: > su p [1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00 [2] s_version: 1 [16] s_ait2.addr2: 0x00001d3a [3] s_size: 0x000000001d1b1da0 s_ait2.address: 7482 [4] s_bsize: 4096 [17] s_logdev: 0x00000830 [5] s_l2bsize: 12 [18] s_logserial: 0x00000078 [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: 0x03a36b2e s_logpxd.address: 61041454 [9] pad: Not Displayed [10] s_agsize: 0x00080000 [22] s_fsckpxd.len: 1914 [11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00 JFS_LINUX [24] s_fsckpxd.addr2: 0x03a363b4 JFS_COMMIT s_fsckpxd.address: 61039540 JFS_GROUPCOMMIT [25] s_time.tv_sec: 0x4586d897 JFS_INLINELOG [26] s_time.tv_nsec: 0x00000000 [27] s_fpack: 'mythstore-D' [12] s_state: 0x00000000 FM_CLEAN [13] s_compress: 0 [14] s_ait2.len: 4 > su s [1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00 [2] s_version: 1 [16] s_ait2.addr2: 0x00001d3a [3] s_size: 0x000000001d1b1da0 s_ait2.address: 7482 [4] s_bsize: 4096 [17] s_logdev: 0x00001640 [5] s_l2bsize: 12 [18] s_logserial: 0x00000077 [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: 0x03a36b2e [9] pad: Not Displayed s_logpxd.address: 61041454 [10] s_agsize: 0x00080000 [22] s_fsckpxd.len: 1914 [11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00 JFS_LINUX [24] s_fsckpxd.addr2: 0x03a363b4 JFS_COMMIT s_fsckpxd.address: 61039540 JFS_GROUPCOMMIT [25] s_time.tv_sec: 0x4586d897 JFS_INLINELOG [26] s_time.tv_nsec: 0x00000000 [27] s_fpack: 'mythstore-D' [12] s_state: 0x00000000 FM_CLEAN [13] s_compress: 0 [14] s_ait2.len: 4 > s2p p [1] s_magic: 'JFS1' [16] s_aim2.len: 2 [2] s_version: 1 [17] s_aim2.addr1: 0x00 [3] s_size: 0x000000001d1b1da0 [18] s_aim2.addr2: 0x00001d38 [4] s_bsize: 4096 s_aim2.address: 7480 [5] s_l2bsize: 12 [19] s_logdev: 0x00000830 [6] s_l2bfactor: 3 [20] s_logserial: 0x00000078 [7] s_pbsize: 512 [21] s_logpxd.len: 8192 [8] s_l2pbsize: 9 [22] s_logpxd.addr1: 0x00 [9] s_agsize: 0x00080000 [23] s_logpxd.addr2: 0x03a36b2e [10] s_flag: 0x10200900 s_logpxd.address: 61041454 LINUX [24] s_fsckpxd.len: 1914 GROUPCOMMIT [25] s_fsckpxd.addr1: 0x00 INLINELOG [26] s_fsckpxd.addr2: 0x03a363b4 s_fsckpxd.address: 61039540 [11] s_state: 0x00000000 [27] s_fsckloglen: 50 CLEAN [28] s_fscklog: 2 [12] s_compress: 0 [29] s_fpack: 'mythstore-D' [13] s_ait2.len: 4 [14] s_ait2.addr1: 0x00 [15] s_ait2.addr2: 0x00001d3a s_ait2.address: 7482 > s2p s [1] s_magic: 'JFS1' [16] s_aim2.len: 2 [2] s_version: 1 [17] s_aim2.addr1: 0x00 [3] s_size: 0x000000001d1b1da0 [18] s_aim2.addr2: 0x00001d38 [4] s_bsize: 4096 s_aim2.address: 7480 [5] s_l2bsize: 12 [19] s_logdev: 0x00001640 [6] s_l2bfactor: 3 [20] s_logserial: 0x00000077 [7] s_pbsize: 512 [21] s_logpxd.len: 8192 [8] s_l2pbsize: 9 [22] s_logpxd.addr1: 0x00 [9] s_agsize: 0x00080000 [23] s_logpxd.addr2: 0x03a36b2e [10] s_flag: 0x10200900 s_logpxd.address: 61041454 LINUX [24] s_fsckpxd.len: 1914 GROUPCOMMIT [25] s_fsckpxd.addr1: 0x00 INLINELOG [26] s_fsckpxd.addr2: 0x03a363b4 s_fsckpxd.address: 61039540 [11] s_state: 0x00000000 [27] s_fsckloglen: 50 CLEAN [28] s_fscklog: 2 [12] s_compress: 0 [29] s_fpack: 'mythstore-D' [13] s_ait2.len: 4 [14] s_ait2.addr1: 0x00 [15] s_ait2.addr2: 0x00001d3a s_ait2.address: 7482 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jfs-discussion mailing list Jfs-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jfs-discussion
