[Ocfs2-users] Huge Problem ocfs2

Fri Nov 9 17:55:20 PST 2012

If global bitmap is gone. then the fs is unusable. But you can extract data
using
the rdump command in debugfs.ocfs. The success depends on how much of the
device is still usable.

On Fri, Nov 9, 2012 at 5:50 PM, Marian Serban <marian at 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 unrecoverable errors while replaying the journals and
> will not continue
>
> After bypassing 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 wrote:
>
> That's the kernel:
>
> Linux ro02xsrv003.bv.easic.ro 2.6.39.4 #6 SMP Mon Dec 12 12:09:49 EET
> 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> Anyway, I tried disabling the metaecc feature, no luck.
>
> [root at ro02xsrv003 ~]# tunefs.ocfs2 --fs-features=nometaecc
> /dev/mapper/volgr1-lvol0
> tunefs.ocfs2: I/O error on channel while opening device
> "/dev/mapper/volgr1-lvol0"
>
> These are the last lines of strace corresponding to the tunefs.ocfs
> command:
>
>
>
> open("/sys/fs/ocfs2/cluster_stack", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f54aad05000
> read(4, "o2cb\n", 4096)                 = 5
> close(4)                                = 0
> munmap(0x7f54aad05000, 4096)            = 0
> open("/sys/fs/o2cb/interface_revision", O_RDONLY) = 4
> read(4, "5\n", 15)                      = 2
> read(4, "", 13)                         = 0
> close(4)                                = 0
> stat("/sys/kernel/config", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> statfs("/sys/kernel/config", {f_type=0x62656570, f_bsize=4096, f_blocks=0,
> f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255,
> f_frsize=4096}) = 0
> open("/dev/mapper/volgr1-lvol0", O_RDONLY) = 4
> ioctl(4, BLKSSZGET, 0x7fffce711454)     = 0
> close(4)                                = 0
> pread(3, "\0\0\v\25\37\1\200\200\202@\21\2\30\26\0\0\0,\17\272\241\4\340\210\311\377\17\300\327\332\373\17"...,
> 4096, 532480) = 4096
> close(3)                                = 0
> write(2, "tunefs.ocfs2", 12tunefs.ocfs2)            = 12
> write(2, ": ", 2: )                       = 2
> write(2, "I/O error on channel", 20I/O error on channel)    = 20
> write(2, " ", 1 )                        = 1
> write(2, "while opening device \"/dev/mappe"..., 47while opening device
> "/dev/mapper/volgr1-lvol0") = 47
> write(2, "\r\n", 2
>
>
>
>
>
> On 10.11.2012 02:06, Sunil Mushran wrote:
>
> It's either that or a check sum problem. Disable metaecc. Not sure which
> kernel you are running.
> We had fixed few problems few years ago around this. If your kernel is
> older, then it could be
> a known issue.
>
>
> On Fri, Nov 9, 2012 at 12:50 PM, Marian Serban <marian at easic.ro> wrote:
>
>> 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
>> errors.
>>
>>
>> Also tried with debugfs.ocfs2:
>>
>>
>> [root at ro02xsrv003 ~]# debugfs.ocfs2  /dev/mapper/volgr1-lvol0
>> debugfs.ocfs2 1.6.3
>> debugfs: ls
>> ls: Bad magic number in inode '.'
>> debugfs: slotmap
>> slotmap: Bad magic number in inode while reading slotmap system file
>> debugfs: stats
>>         Revision: 0.90
>>         Mount Count: 0   Max Mount Count: 20
>>         State: 0   Errors: 0
>>         Check Interval: 0   Last Check: Fri Nov  9 14:35:53 2012
>>         Creator OS: 0
>>         Feature Compat: 3 backup-super strict-journal-super
>>         Feature Incompat: 16208 sparse extended-slotmap inline-data
>> metaecc xattr indexed-dirs refcount discontig-bg
>>         Tunefs Incomplete: 0
>>         Feature RO compat: 7 unwritten usrquota grpquota
>>         Root Blknum: 129   System Dir Blknum: 130
>>         First Cluster Group Blknum: 64
>>         Block Size Bits: 12   Cluster Size Bits: 18
>>         Max Node Slots: 10
>>         Extended Attributes Inline Size: 256
>>         Label: SAN
>>         UUID: B4CF8D4667AF43118F3324567B90A987
>>         Hash: 3698209293 (0xdc6e320d)
>>         DX Seed[0]: 0x9f4a2bb7
>>         DX Seed[1]: 0x501ddac0
>>         DX Seed[2]: 0x6034bfe8
>>         Cluster stack: classic o2cb
>>         Inode: 2   Mode: 00   Generation: 1093568923 (0x412e899b)
>>         FS Generation: 1093568923 (0x412e899b)
>>         CRC32: 46f2d360   ECC: 04d4
>>         Type: Unknown   Attr: 0x0   Flags: Valid System Superblock
>>         Dynamic Features: (0x0)
>>         User: 0 (root)   Group: 0 (root)   Size: 0
>>         Links: 0   Clusters: 45340448
>>         ctime: 0x4ee67f67 -- Tue Dec 13 00:25:43 2011
>>         atime: 0x0 -- Thu Jan  1 02:00:00 1970
>>         mtime: 0x4ee67f67 -- Tue Dec 13 00:25:43 2011
>>         dtime: 0x0 -- Thu Jan  1 02:00:00 1970
>>         ctime_nsec: 0x00000000 -- 0
>>         atime_nsec: 0x00000000 -- 0
>>         mtime_nsec: 0x00000000 -- 0
>>         Refcount Block: 0
>>         Last Extblk: 0   Orphan Slot: 0
>>         Sub Alloc Slot: Global   Sub Alloc Bit: 65535
>>
>>
>>
>>
>> Marian
>>
>>
>> _______________________________________________
>> Ocfs2-users mailing list
>> Ocfs2-users at oss.oracle.com
>> https://oss.oracle.com/mailman/listinfo/ocfs2-users
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-users/attachments/20121109/07461d90/attachment-0001.html 