----- Original Message -----
| Hi Bob
| You can download the disk.dump file via this URLHi Sherlock,
| and the file's md5sum is
| 1e43719ca086220478a9aee9c09c727b disk.dump
| if is there anything other can help ascertain the problem please let
| Thank you
I've taken a close look at the image file you created.
This appears to be a normal, everyday GFS2 file system
except there is a section of 16 blocks (or 0x10 in hex)
that are completely destroyed near the beginning of the
file system, right after the root directory. Unfortunately,
there are critical system files like the master directory
that were overwritten.
Blocks 35 through 50 are overwritten by unrecognisable
binary data. There's no way to tell how this happened.
You might be able to recover the file system if you find
a copy of the image from before the corruption and copy
the corrupted 16 blocks from that. For example, you could
use a command like this:
dd if=/dev/backup.image of=/dev/your/device bs=4K skip=35 seek=35 count=16 conv=notrunc
You would also need to fix up the locking protocol with:
gfs2_tool sb /dev/your/device proto "lock_dlm"
Without those 16 destroyed blocks, you may not be able to
recover the file system.
As a last-ditch effort, you could try running the experimental
fsck.gfs2 for RHEL6 located on my people page to see if it
can recreate any of the data, but it's a long shot, and unlikely
I hope this helps.
Red Hat File Systems
Linux-cluster mailing list
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster