[Linux-cluster] unformat gfs2

[Bob Peterson]

----- Original Message -----
> I have accidentally reformatted a GFS cluster.
> We need to unformat it.. is there any way to recover disk ?
> 
> I read this post
> http://web.archiveorange.com/archive/v/TUhSn11xEn9QxXBIZ0k6
> 
> it say that I can use gfs2_edit to recover data.
> I need more details about changing block map to 0xff
> 
> tnx

Hi,

Sorry to hear about your file system mishap.

It's not clear from your post whether you mean GFS or GFS2. Your subject
like says GFS2, but your comment said you reformatted it to GFS.
So my first questions are: What was it really? and What is it now?

Assuming it was, and still is, gfs2, there's another important question:
Was the file system _ever_ grown via gfs2_grow since the very first mkfs?
If so, the subsequent mkfs would most likely place the resource groups in
a different location, so the file system would be damaged beyond repair.

The next important question is: did you override any of the mkfs.gfs2
parameters either the first time or the second time, like -b, -J, -j,
or -r? Once again, if you specified a different block size (-b) or
resource group size, the second mkfs.gfs2 would have placed the
resource groups in different locations, once again damaging the original
contents beyond repair.

The third important question is: Was the device altered in any other
way, for example, mkfs.ext4 or mkfs.xfs, which might have changed things?
If so, it's probably done irreparable damage.

However, if you never ran gfs2_grow, and never overrode -b or -r during
either mkfs, the mkfs would likely have placed the resource groups in the
exact same locations as it did the first time. In that case, you might
be able to repair the file system by doing what you describe: Setting
all the bits in the bitmaps to 0xff, then letting fsck.gfs2 sort it out.

Unfortunately, there is no tool that can do this en-mass.
You could manually set the bits to 0xff with gfs2_edit, but depending
on the size of the file system, it would take a very long time.

If it was my valuable data, and I had no backup, I would first
make a block-for-block copy of the entire device so I had a sandbox
to run experiments on. Next, I'd write a program that opened the block
device, did a block-by-block search for GFS2 dinodes, then twiddle that
block's bitmap from 0 to 3. Then I'd run fsck.gfs2 to see how well it can
put the pieces back together. That program would have to be a hybrid
with pieces pulled from fsck.gfs2 and gfs2_edit. It's no small task,
and you'd have to know what you're doing. Unfortunately, there are only
a handful of programmers who know enough about this to do it correctly
(I'm one of them). All of them work for Red Hat. As much as it sounds
like a fun project, it would probably be considered a conflict of
interest, unless you somehow hired Red Hat and got my management
involved. If I got their blessing, I'd be happy to do this. The trouble is,
even with such a program, there are no guarantees that your file system
would be back the way it used to be. It would likely be cheaper and
better to restore from a backup.

Regards,

Bob Peterson
Red Hat File Systems