Re: falure during gfs2_grow caused node crash & data loss

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

 




In the message dated: Mon, 22 Mar 2010 13:18:31 EDT,
The pithy ruminations from Bob Peterson on 
<Re:  falure during gfs2_grow caused node crash & data loss> wer
e:
=> ----- bergman@xxxxxxxxxxxx wrote:
=> (snip)
=> | Do you mean "di_size"?
=> 
=> Yes.
=>  
=> | => to be a fairly small multiple of 96 then repeat steps 1 through 4.
=> | 
=> | According to "gfs2_edit -p rindex", the initial value of di_size is:
=> | 
=> | 	di_size               8192                0x2000
=> | 
=> | Does that give any indication of an appropriate "fairly small
=> | multiple"?
=> | 
=> | Thanks,
=> | 
=> | Mark
=> 
=> Hi Mark,
=> 
=> The big question is: Was this file system created with mkfs.gfs2
=> originally?  Or was it created with gfs_mkfs (gfs1) and converted to

Nope.

=> gfs2 by gfs2_convert?  If it was created by gfs_mkfs and converted

Yes.

=> then there's not much hope of recovering because fsck.gfs2 isn't
=> currently smart enough to handle oddly-spaced rgrps left behind by gfs1.

Ouch.

=> 
=> Here's the problem: fsck.gfs2 seems to be claiming that there are six
=> rgrps intact, each of which is around 1GB.  Since the file system was
=> originally much bigger, I'd think there would be more.  Each of the
=> rindex entries is 96 bytes, so you could try 6*96 = 576, or in hex 0x240.
=> So basically you could try setting di_size to 0x240 with gfs2_edit, then
=> mount and run gfs2_grow.  Then unmount and run fsck.gfs2.
=> 
=> As I said, if the file system was originally gfs1, this won't work.


The filesystem was originally gfs1.

I converted it to gfs2. Running fsck.gfs2 was successful, then it crashed when 
trying to grow the gfs2 filesystem.
 

Questions:

	1. Is there any way to tell (ie. "gfs2_edit -p" or "lvs") whether
		a gfs2 volume was originally gfs1? I've got several more
		gfs2 volumes, some of which may have been gfs1 originally.

	2. Is there any safe way to run gfs2_grow on a gfs2 volume that was
		born as gfs1?


=> 
=> If the file system was gfs2 from its conception, hopefully gfs2_grow
=> will rewrite those damaged rgrps starting with the damaged one, and
=> then fsck.gfs2 will take care of finding out what is allocated and not
=> allocated and fix the bitmaps.  If the file system was full before
=> gfs2_grow, you could lose a lot of data.  It's a long shot, really,
=> but I guess you've got nothing more to lose.

OK. I'll proceed with the restore from backups.

Thanks,

Mark

=> 
=> Regards,
=> 
=> Bob Peterson
=> Red Hat File Systems
=> 



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