Hi Eric,
Thanks for your reply.
Actually my boss requested me to bring back the file system yesterday, at the
cost of our media data (and half my monthly payment) to continue our service.?
Can you show me how to get debug information for this case (or documentation
about it) ? Actually I'm not very familiar with GDB or debugging techniques,
but I will try to reproduce the situation and solve it to prevent future
problems like this to happen.
Sent?from?my?BlackBerry?10?smartphone.
? Original Message ?
From: Eric Ren
Sent: 13:38 Th? ba, ng?y 24 th?ng n?m n?m 2016
To: Mailer Regs; ocfs2-users at oss.oracle.com
Subject: Re: [Ocfs2-users] OCFS2 - Bad magic number
Hello,
I don't encounter this so far. You can install relative ocfs2-tools
debug packages and gdb to find out what's happening. And get your
findings back to us;-)
To me, it look like a DLM issue, not super block.
Eric
On 05/22/2016 05:44 AM, Mailer Regs wrote:> 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 at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-users
>