[Ocfs2-users] OCFS2 - Bad magic number

[Mailer Regs]

Hi LQ friends,

I have a problem with our OCFS2 cluster, which I couldn't solve by myself.
In short, I have a OCFS2 cluster with 3 nodes and a shared storage LUN. I
have mapped the LUN to all 3 of the nodes, and split the LUN into 2
partitions, formatted them as OCFS2 filesystems and mounted them
successfully. The system has been running OK for nearly 2 years, but today
the partition 1 suddenly is not accessible. I have to reboot 1 node. After
rebooting, the partition 2 is mounted OK, but the partition 1 cannot be
mounted.
The error is below:

# mount -t ocfs2 /dev/mapper/mpath3p1 /test
mount.ocfs2: Bad magic number in inode while trying to determine
heartbeat information

# fsck.ocfs2  /dev/mapper/mpath3p1
fsck.ocfs2 1.6.3
fsck.ocfs2: Bad magic number in inode while initializing the DLM

# fsck.ocfs2 -r 2 /dev/mapper/mpath3p1
fsck.ocfs2 1.6.3
[RECOVER_BACKUP_SUPERBLOCK] Recover superblock information from backup
block#1048576? <n> y
fsck.ocfs2: Bad magic number in inode while initializing the DLM

# parted /dev/mapper/mpath3
GNU Parted 1.8.1
Using /dev/mapper/mpath3
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print

Model: Linux device-mapper (dm)
Disk /dev/mapper/mpath3: 20.0TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  10.2TB  10.2TB               primary
 2      10.2TB  20.0TB  9749GB               primary



Usually, the bad magic number happens when the super block is corrupted,
and I have experienced several similar cases before, which can be solved
quickly by using backup super blocks. But this case is different, I cannot
fix the problem by simply replacing the super block, thus I'm out of ideas.

Please take a look and suggest me how to solve this problem, as I need to
recover the data, it's the most important goal now.

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-users/attachments/20160522/42856fa2/attachment.html