Hi Sunil,
Thank you for answering. Unfortunately, it doesn't seem like it's a
hardware problem. There's no way a cable can be loose because it's iSCSI
over 1G Ethernet (copper wires) environment. Also I performed dd
if=/dev/ of=/dev/null and first 16GB or so are fine. Dmesg shows
no
journal replay function, I got
Pass 0a: Checking cluster allocation chains
pass0: Bad magic number in inode while looking up the global bitmap inode
fsck.ocfs2: Bad magic number in inode while performing pass 0
Does it mean the filesystem is destroyed completely?
On 10.11.2012 02:54, Marian Serban
at 5:50 PM, Marian Serban mar...@easic.ro
mailto:mar...@easic.ro wrote:
I tried hacking the fsck.ocfs2 source code by not considering
metaecc flag. Then I ran into
journal recovery: Bad magic number in inode while looking up the
journal inode for slot 0
fsck encountered
the
root dir is gone. Maybe
best to look into your backups.
On Fri, Nov 9, 2012 at 6:01 PM, Marian Serban mar...@easic.ro
mailto:mar...@easic.ro wrote:
Nope, rdump doesn't work either.
debugfs: rdump -v / /tmp
Copying to /tmp/
rdump: Bad magic number in inode while reading inode 129
