[Linux-cluster] unformat gfs2

[Mr.Pine]

On Tue, Mar 18, 2014 at 8:08 PM, Bob Peterson <rpeterso at redhat.com> wrote:
>
> ----- 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?

It's GFS2 .

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

Without any use of gfs2_grow,

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

All options are equal ..

> 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

No,
.
>
> 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

There is many many block types (http://linux.die.net/man/8/gfs2_edit),
Do we find 4 (Dinode)? instead of for example 3 (Resource Group Bitmap)?

How we could fine bitmaps?

> 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
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster