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.
_______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-users