Re: error messages while use fsck.gfs2

[Sherlock Zhang <sherlock_zhang@xxxxxxxxxx>]

BTW:

The stdout info

[root@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@xxxxxxxxxx> 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"

and the file's md5sum is

ec92b4d5f84e52a91e9128a789da4579  disk.dg03.dump

On Mon, Nov 14, 2011 at 11:00 PM, Bob Peterson <rpeterso@xxxxxxxxxx> 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@xxxxxxxxxx
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


*************************************************************************************************

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster