Hi all
There are 4 storage with RAID5 and last time the dg02 was gone and the
repair are still progress.
but today I was been told there is another dg has gone :(
this time I didn't get any info from the disk, did any one could tell me
why would this happen.
the disk dump info can download via this URL
"http://www.waalker.com/disk.dg03.dump <http://www.waalker.com/disk.dump>"
and the file's md5sum is
ec92b4d5f84e52a91e9128a789da4579 disk.dg03.dump
On Mon, Nov 14, 2011 at 11:00 PM, Bob Peterson <rpete...@redhat.com> wrote:
> ----- 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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
--
Thank you
Best regards
*************************************************************************************************
Sherlock Zhang 张 国荣
Technical Supporter East China Technical Support Department
Address: Room 23E No. 728 West Yanan Road Changning DC. Shanghai China
Post code: 20050
Office: +86 021 62253300 ext. 803
Mobile: +86 133 8600 6305
www.uit.com.cn
*************************************************************************************************
--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster
