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
