----- Original Message ----- | Hi Bob | You can download the disk.dump file via this URL | "http://www.waalker.com/disk.dump"; | and the file's md5sum is | 1e43719ca086220478a9aee9c09c727b disk.dump | if is there anything other can help ascertain the problem please let | me | know. | | Thank you Hi Sherlock, 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 to work: http://people.redhat.com/rpeterso/Experimental/RHEL6.x/fsck.gfs2 I hope this helps. Regards, Bob Peterson Red Hat File Systems -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
