[Linux-cluster] error messages while use fsck.gfs2

Sherlock Zhang sherlock_zhang at uit.com.cn
Thu Dec 22 07:34:31 UTC 2011


BTW:
The stdout info
[root at Toureg ~]# fsck.gfs2 /dev/sdc
Initializing fsck
Either the super block is corrupted, or this is not a GFS2 filesystem
Gathering information to repair the gfs2 superblock.  This may take some
time.
Block size determined to be: 4096
Found system jindex file at: 0x24
Found system per_node directory at: 0x2816f
>From per_node's '..' I backtracked the master directory to: 0x23
Found system statfs file at: 0x28171
Found system quota file at: 0x28172
Found system inum file at: 0x2867f
Found system rindex file at: 0x28681
Lock protocol determined to be: lock_nolock
Stand-alone file system: No need for a lock table.
Okay to fix the GFS2 superblock? (y/n)y
bad seek: Invalid argument from inode_read:58: block 18446744073709551615
(0xffffffffffffffff)

On Thu, Dec 22, 2011 at 3:30 PM, Sherlock Zhang
<sherlock_zhang at uit.com.cn>wrote:

> 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 <rpeterso at 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 at 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
>
>
>
> *************************************************************************************************
>



-- 
 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


*************************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20111222/2489b1fb/attachment.htm>


More information about the Linux-cluster mailing list