IO error on channel means the system cannot talk to the block device. The
problem
is in the block layer. Maybe a loose cable or a setup problem.
dmesg should show errors.
On Fri, Nov 9, 2012 at 10:46 AM, Laurentiu Gosu l...@easic.ro wrote:
Hi,
I'm using ocfs2 cluster in a production
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
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
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 mar...@easic.ro wrote:
I tried hacking the fsck.ocfs2 source code
Nope, rdump doesn't work either.
debugfs: rdump -v / /tmp
Copying to /tmp/
rdump: Bad magic number in inode while reading inode 129
rdump: Bad magic number in inode while recursively dumping inode 129
Could you please confirm that it's enough to just force the return value
of 0 at
Yes that should be enough for that. But that won't help if the real problem
is device related.
What does debugfs.ocfs2 -R ls -l / return? If that errors, means 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 wrote:
debugfs: ls /
ls: Bad magic number in inode while checking directory at block 129
On 10.11.2012 04:24, Sunil Mushran wrote:
Yes that should be enough for that. But that won't help if the real
problem is device related.
What does debugfs.ocfs2 -R ls -l / return? If that errors, means the
Hi Sunil,
Do you ANY other idea to recover our data? Maybe you know same recovery
tool that we could use? We would really need it.
Thank you for your help.
Laurentiu.
On 11/10/2012 04:25, Marian Serban wrote:
debugfs: ls /
ls: Bad magic number in inode while checking directory at block 129
