<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Sunil,<br>
Do you ANY other idea to recover our data? Maybe you know same
recovery tool that we could use? We would really need it.<br>
Thank you for your help.<br>
Laurentiu.<br>
<br>
On 11/10/2012 04:25, Marian Serban wrote:<br>
</div>
<blockquote cite="mid:509DBB18.2060306@easic.ro" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><tt>debugfs: ls /</tt><tt><br>
</tt><tt>ls: Bad magic number in inode while checking directory
at block 129</tt><tt><br>
</tt><br>
<br>
<br>
On 10.11.2012 04:24, Sunil Mushran wrote:<br>
</div>
<blockquote
cite="mid:CAEeiSHXnZio7e3xbLZzNovrtDcEmGYGSArQV9OtpEFhZkCR8Hg@mail.gmail.com"
type="cite">Yes that should be enough for that. But that won't
help if the real problem is device related.
<div><br>
</div>
<div>What does debugfs.ocfs2 -R "ls -l /" return? If that
errors, means the root dir is gone. Maybe</div>
<div>best to look into your backups.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Nov 9, 2012 at 6:01 PM,
Marian Serban <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:marian@easic.ro" target="_blank">marian@easic.ro</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Nope, rdump doesn't work either.<br>
<br>
<tt>debugfs: rdump -v / /tmp</tt><tt><br>
</tt><tt>Copying to /tmp/</tt><tt><br>
</tt><tt>rdump: Bad magic number in inode while
reading inode 129</tt><tt><br>
</tt><tt>rdump: Bad magic number in inode while
recursively dumping inode 129</tt><tt><br>
</tt><br>
<br>
Could you please confirm that it's enough to just
force the return value of 0 at
"ocfs2_validate_meta_ecc" in order to bypass the ECC
checks?
<div>
<div class="h5"><br>
<br>
<br>
<br>
On 10.11.2012 03:55, Sunil Mushran wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<blockquote type="cite">
<div>If global bitmap is gone. then the fs is
unusable. But you can extract data using</div>
<div>the rdump command in debugfs.ocfs. The
success depends on how much of the</div>
<div>device is still usable.</div>
<div class="gmail_extra"> <br>
<br>
<div class="gmail_quote">On Fri, Nov 9, 2012 at
5:50 PM, Marian Serban <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:marian@easic.ro"
target="_blank">marian@easic.ro</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>I tried hacking the fsck.ocfs2 source
code by not considering metaecc flag.
Then I ran into <br>
<br>
<tt>journal recovery: Bad magic number
in inode while looking up the journal
inode for slot 0</tt>
<div><tt><br>
</tt><tt>fsck encountered
unrecoverable errors while replaying
the journals and will not continue</tt><tt><br>
</tt><br>
</div>
After bypassing journal replay function,
I got <br>
<br>
<tt>Pass 0a: Checking cluster allocation
chains</tt><tt><br>
</tt><tt>pass0: Bad magic number in
inode while looking up the global
bitmap inode</tt><tt><br>
</tt><tt>fsck.ocfs2: Bad magic number in
inode while performing pass 0</tt><tt><br>
</tt><br>
<br>
Does it mean the filesystem is destroyed
completely?
<div>
<div><br>
<br>
<br>
<br>
On 10.11.2012 02:54, Marian Serban
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div>That's the kernel:<br>
<br>
<tt>Linux <a
moz-do-not-send="true"
href="http://ro02xsrv003.bv.easic.ro"
target="_blank">ro02xsrv003.bv.easic.ro</a>
2.6.39.4 #6 SMP Mon Dec 12
12:09:49 EET 2011 x86_64 x86_64
x86_64 GNU/Linux</tt><tt><br>
</tt><br>
Anyway, I tried disabling the
metaecc feature, no luck.<br>
<br>
<tt>[root@ro02xsrv003 ~]#
tunefs.ocfs2
--fs-features=nometaecc
/dev/mapper/volgr1-lvol0</tt><tt><br>
</tt><tt>tunefs.ocfs2: I/O error
on channel while opening device
"/dev/mapper/volgr1-lvol0"</tt><tt><br>
</tt><br>
These are the last lines of strace
corresponding to the tunefs.ocfs
command:<br>
<tt><br>
<br>
<br>
open("/sys/fs/ocfs2/cluster_stack",
O_RDONLY) = 4<br>
fstat(4, {st_mode=S_IFREG|0644,
st_size=4096, ...}) = 0<br>
mmap(NULL, 4096,
PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f54aad05000<br>
read(4, "o2cb\n",
4096) = 5<br>
close(4)
= 0<br>
munmap(0x7f54aad05000,
4096) = 0<br>
open("/sys/fs/o2cb/interface_revision",
O_RDONLY) = 4<br>
read(4, "5\n",
15) = 2<br>
read(4, "",
13) = 0<br>
close(4)
= 0<br>
</tt><tt>stat("/sys/kernel/config",
{st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>open("/dev/mapper/volgr1-lvol0",
O_RDONLY) = 4</tt><tt><br>
</tt><tt>ioctl(4, BLKSSZGET,
0x7fffce711454) = 0</tt><tt><br>
</tt><tt>close(4)
= 0</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>close(3)
= 0</tt><tt><br>
</tt><tt>write(2, "tunefs.ocfs2",
12tunefs.ocfs2) = 12</tt><tt><br>
</tt><tt>write(2, ": ", 2:
) = 2</tt><tt><br>
</tt><tt>write(2, "I/O error on
channel", 20I/O error on
channel) = 20</tt><tt><br>
</tt><tt>write(2, " ", 1
) = 1</tt><tt><br>
</tt><tt>write(2, "while opening
device \"/dev/mappe"..., 47while
opening device
"/dev/mapper/volgr1-lvol0") = 47</tt><tt><br>
</tt><tt>write(2, "\r\n", 2</tt><tt><br>
</tt><br>
<br>
<br>
<br>
<br>
On 10.11.2012 02:06, Sunil Mushran
wrote:<br>
</div>
<blockquote type="cite">It's either
that or a check sum problem.
Disable metaecc. Not sure which
kernel you are running.
<div>We had fixed few problems few
years ago around this. If your
kernel is older, then it could
be</div>
<div>a known issue.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri,
Nov 9, 2012 at 12:50 PM,
Marian Serban <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:marian@easic.ro"
target="_blank">marian@easic.ro</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> Hi
Sunil,<br>
<br>
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.<br>
<br>
<br>
Also tried with
debugfs.ocfs2:<br>
<br>
<br>
[root@ro02xsrv003 ~]#
debugfs.ocfs2
/dev/mapper/volgr1-lvol0<br>
debugfs.ocfs2 1.6.3<br>
debugfs: ls<br>
ls: Bad magic number in
inode '.'<br>
debugfs: slotmap<br>
slotmap: Bad magic number in
inode while reading slotmap
system file<br>
debugfs: stats<br>
Revision: 0.90<br>
Mount Count: 0 Max
Mount Count: 20<br>
State: 0 Errors: 0<br>
Check Interval: 0
Last Check: Fri Nov 9
14:35:53 2012<br>
Creator OS: 0<br>
Feature Compat: 3
backup-super
strict-journal-super<br>
Feature Incompat:
16208 sparse
extended-slotmap inline-data
metaecc xattr indexed-dirs
refcount discontig-bg<br>
Tunefs Incomplete: 0<br>
Feature RO compat: 7
unwritten usrquota grpquota<br>
Root Blknum: 129
System Dir Blknum: 130<br>
First Cluster Group
Blknum: 64<br>
Block Size Bits: 12
Cluster Size Bits: 18<br>
Max Node Slots: 10<br>
Extended Attributes
Inline Size: 256<br>
Label: SAN<br>
UUID:
B4CF8D4667AF43118F3324567B90A987<br>
Hash: 3698209293
(0xdc6e320d)<br>
DX Seed[0]:
0x9f4a2bb7<br>
DX Seed[1]:
0x501ddac0<br>
DX Seed[2]:
0x6034bfe8<br>
Cluster stack:
classic o2cb<br>
Inode: 2 Mode: 00
Generation: 1093568923
(0x412e899b)<br>
FS Generation:
1093568923 (0x412e899b)<br>
CRC32: 46f2d360
ECC: 04d4<br>
Type: Unknown
Attr: 0x0 Flags: Valid
System Superblock<br>
Dynamic Features:
(0x0)<br>
User: 0 (root)
Group: 0 (root) Size: 0<br>
Links: 0 Clusters:
45340448<br>
ctime: 0x4ee67f67 --
Tue Dec 13 00:25:43 2011<br>
atime: 0x0 -- Thu
Jan 1 02:00:00 1970<br>
mtime: 0x4ee67f67 --
Tue Dec 13 00:25:43 2011<br>
dtime: 0x0 -- Thu
Jan 1 02:00:00 1970<br>
ctime_nsec:
0x00000000 -- 0<br>
atime_nsec:
0x00000000 -- 0<br>
mtime_nsec:
0x00000000 -- 0<br>
Refcount Block: 0<br>
Last Extblk: 0
Orphan Slot: 0<br>
Sub Alloc Slot:
Global Sub Alloc Bit:
65535<span><font
color="#888888"><br>
<br>
<br>
<br>
<br>
Marian<br>
<br>
</font></span><br>
_______________________________________________<br>
Ocfs2-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Ocfs2-users@oss.oracle.com"
target="_blank">Ocfs2-users@oss.oracle.com</a><br>
<a moz-do-not-send="true"
href="https://oss.oracle.com/mailman/listinfo/ocfs2-users"
target="_blank">https://oss.oracle.com/mailman/listinfo/ocfs2-users</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ocfs2-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ocfs2-users@oss.oracle.com">Ocfs2-users@oss.oracle.com</a>
<a class="moz-txt-link-freetext" href="https://oss.oracle.com/mailman/listinfo/ocfs2-users">https://oss.oracle.com/mailman/listinfo/ocfs2-users</a></pre>
</blockquote>
<br>
</body>
</html>