Re: fsck.gfs2 The root dinode block is destroyed.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Great Thanks.

This particular mount has two partitions.  I get the following when i
use the savemeta/savemetaslow commands.  Is this ok or do I need to do
something different to gather the information?  I wasn't sure if the
information was just on the first partition or on each partition.

[root@-dr tmp]# gfs2_edit savemetaslow /dev/sdd1 /tmp/sdd1.meta
There are 488281088 blocks of 4096 bytes in the destination device.
Reading resource groups...Done. File system size: 0.0
Metadata saved to file /tmp/sdd1.meta (gzipped, level 9).
[root@-dr tmp]# gfs2_edit savemetaslow /dev/sdd2 /tmp/sdd2.meta
Either the super block is corrupted, or this is not a GFS2 filesystem
Unable to read superblock.
[root@dr tmp]# gfs2_edit savemetaslow /dev/sdd /tmp/sdd.meta
Either the super block is corrupted, or this is not a GFS2 filesystem
Unable to read superblock.
[root@-dr tmp]#



On Tue, Mar 29, 2016 at 10:34 AM, Bob Peterson <rpeterso@xxxxxxxxxx> wrote:
> ----- Original Message -----
>> Good Morning,
>>
>> We have a large cluster with 50 gfs2 SAN mounts.  The mounts range in
>> size from 1TB to 15TB each.  We have some with 6-8TB of data but most
>> average around 3TB used right now.  We were doing network testing a
>> while back to check our redundancy incase of a switch failure, and the
>> tests failed..  multiple times.  We ended having the SAN mounts yanked
>> out from under the cluster.  Long story short, we seem to have
>> corruption.  I can still bring the volumes up with the cluster but
>> when i take everything down and do a fsck I get the following:
>>
>>
>> (ran with fsck -n /dev/$device)
>>
>> Found a copy of the root directory in a journal at block: 0x501ca.
>> Damaged root dinode not fixed.
>> The root dinode should be at block 0x2f3b98b7 but it seems to be destroyed.
>> Found a copy of the root directory in a journal at block: 0x501d2.
>> Damaged root dinode not fixed.
>> The root dinode should be at block 0x28a3ac7f but it seems to be destroyed.
>> Found a copy of the root directory in a journal at block: 0x501da.
>> Damaged root dinode not fixed.
>> Unable to locate the root directory.
>> Can't find any dinodes that might be the root; using master - 1.
>> Found a possible root at: 0x16
>> The root dinode block is destroyed.
>> At this point I recommend reinitializing it.
>> Hopefully everything will later be put into lost+found.
>> The root dinode was not reinitialized; aborting.
>>
>>
>> This particular device had 4698 "seems to be destroyed..  found a
>> copy" messages before the final, "Can't find any dinodes" message.  I
>> fear that we have a number of mounts in this state.
>>
>>  Is there any way to recover?  Thanks in advance.
>
> Hi Megan,
>
> I can't tell what's "really" going on unless I examine the GFS2 file system
> metadata up close. If you save the metadata (gfs2_edit savemeta <device> <file>)
> and also the first 1MB of the block device, and somehow get it to me, I might
> be able to figure out what's going on, how it got that way, and what to do to
> recover it. Ordinarily, the root directory appears early in the metadata and
> it should not be deleted. What was the history of the file system? Was it
> converted from GFS1 with gfs2_convert or something?
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems
>
> --
> Linux-cluster mailing list
> Linux-cluster@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/linux-cluster

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



[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux