Hi, after a power failure, all superblocks of my raid0 disks (all of them formatted with jfs) seem to be scrap. Those partitions, that were not in the raid array are just fine.
I have put two equal partitions (same size, same fs, same position on the
hard disc) into each of my 4 raid0 arrays. All those disks are encrypted
with cryptoloop. Cryptoloop works just fine and raid doesn't complain
either but as soon as I want to mount the raid arrays, I get a:
'mount: wrong fs type, bad option, bad superblock on /dev/loop0,
or too many mounted file systems'
My next step was to mount the single partitions without raid. It failed
with the same error message. (What a surprise for raid0.) After that I
only worked with the single partitions to avoid raid problems. (And since
I'm anything but an expert, it feels save to have a backup handy, even if
it's a broken one.)
I ran fsck (Standard and 'jfs_fsck -n') on the disks. It always reported
that no valid jfs superblock could be found. After that I started
jfs_debugfs to have look on the superblocks. Apparently, field [1] had
been scrambled and I resetted it to 'JFS1'. (I copied that value from the
superblock of one of the working jfs partitions.)
After that, 'fsck.jfs -v' delivered the following for all (important)
partitions:
fsck.jfs version 1.1.7, 22-Jul-2004
processing started: 8/15/2005 21.46.22
Using default parameter: -p
The current device is: /dev/loop5
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: 10486420
**Phase 0 - Replay Journal Log
LOGREDO: Log superblock contains invalid magic number.
logredo failed (rc=-268). fsck continuing.
**Phase 1 - Check Blocks, Files/Directories, and Directory Entries
Invalid stamp detected in file system object MA2.
Primary metadata inode A2 is corrupt.
Invalid stamp detected in file system object MA2.
Secondary metadata inode A2 is corrupt.
Errors detected in the Primary File/Directory Allocation Table.
Errors detected in the Secondary File/Directory Allocation Table.
CANNOT CONTINUE.
processing terminated: 8/15/2005 21:46:22 with return code: -10049 exit
code: 4.
(On one partition fsck.jfs reported a corrupted superblock but since this
partition has almost no important data on it, I don't care too much about
it.)
jfs_debugfs now shows the superblock of the other three partions (loop4,
loop6 and loop7 attachments; got them by stdout-redirection: first 'su p',
then 'su s') like this of loop 4:
fs_debugfs version 1.1.7, 22-Jul-2004
Aggregate Block Size: 4096
primary superblock:
[1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00
[2] s_version: 1 [16] s_ait2.addr2: 0x00000518
[3] s_size: 0x0000000004ff0908 s_ait2.address: 1304
[4] s_bsize: 4096 [17] s_logdev: 0x00000700
[5] s_l2bsize: 12 [18] s_logserial: 0x00000016
[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: 0x009fe294
[9] pad: Not Displayed s_logpxd.address: 10478228
[10] s_agsize: 0x00020000 [22] s_fsckpxd.len: 371
[11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00
JFS_LINUX [24] s_fsckpxd.addr2: 0x009fe121
JFS_COMMIT JFS_GROUPCOMMIT s_fsckpxd.address: 10477857
JFS_INLINELOG [25] s_time.tv_sec: 0x41c555ad
[26] s_time.tv_nsec: 0x00000000
[27] s_fpack: ''
[12] s_state: 0x00000001
FM_MOUNT
[13] s_compress: 0
[14] s_ait2.len: 4
secondary superblock
[1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00
[2] s_version: 1 [16] s_ait2.addr2: 0x00000518
[3] s_size: 0x0000000004ff0908 s_ait2.address: 1304
[4] s_bsize: 4096 [17] s_logdev: 0x00000700
[5] s_l2bsize: 12 [18] s_logserial: 0x00000014
[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: 0x009fe294
[9] pad: Not Displayed s_logpxd.address: 10478228
[10] s_agsize: 0x00020000 [22] s_fsckpxd.len: 371
[11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00
JFS_LINUX [24] s_fsckpxd.addr2: 0x009fe121
JFS_COMMIT JFS_GROUPCOMMIT s_fsckpxd.address: 10477857
JFS_INLINELOG [25] s_time.tv_sec: 0x41c555ad
[26] s_time.tv_nsec: 0x00000000
[27] s_fpack: ''
[12] s_state: 0x00000000
FM_CLEAN
[13] s_compress: 0
[14] s_ait2.len: 4
I have attached the output of a well working partition (hda6) for comparison.
I did google for similar problems but found nothing really helpfull.
'od -x -v -N 64 /dev/loop4 +0x1000' just get's me a lot of zeros:
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000100
I copied it from a mailiniglist post and guess that the offset is wrong
(same output for the good partition), but I don't know, what the right
offset would be.
My Box is a SuSE 9.2 and I'm working with their standard JFS filesystem. I
don't know, if they are using any special flavor. It's an AMD Duron
processor (x386). The raid0 is linux software raid. And I'm anything but
an expert, as I've mentioned before.
Is there a real chance of repairing those superblocks and where can I find
hints how to do it? I've googled and found the information that carried me
through the examinations that I've described above but I haven't found
anything to go on from here.
Thanks for your consideration,
Simon Hoerder
P.S. I know I'm paying the price for beeing to lazy for additional backup
copies.
output-loop4.jfs_debugfs
Description: Binary data
output-loop6.jfs_debugfs
Description: Binary data
output-loop7.jfs_debugfs
Description: Binary data
output-hda6.jfs_debugfs
Description: Binary data
