[Linux-cluster] unformat gfs2

[Mr.Pine]

Good news for all :
I successfully recoved all of my data(1.5TB) without even one bit lost!
my program tooks only 1 hour to do all the jobs on my 1.7 TB
partition.(I could not wait 100 days for my bash script to finish).

I will publish my  source code very soon for the public use.

Special thanks to Bob for the help.

Mr.Pine

On Wed, Mar 19, 2014 at 4:58 PM, Bob Peterson <rpeterso at redhat.com> wrote:
> ----- Original Message -----
>> Hi,
>>
>> Scripts is very very slow, so i should write program in c/c++.
>>
>> I need some confidence about data structures and data location on disk.
>> As i reviewed blocks of data:
>>
>> All reserved blocks (GFS2 specific blocks) start by : 0x01161970
>> Blocktype store location is at Byte # 8,
>> Type of start block of each resource group is: 2
>> Bitmaps are in block types 2 & 3.
>> In block type 2, bitmap info starts from Byte # 129
>> In block type 3, bitmap info starts from Byte # 25
>> Length of RGs are const, 5 in my volume (out put of gfs2_edit -p rindex
>> /dev/..)
>>
>> Is this info right?
>>
>> Logic of my program seams should be like this:
>>
>> (1)
>> Loop in device and temporary store block id of dinode blocks, and also
>> their bitmap locations
>>
>> (2)
>> Change bitmap of blocks to 3 (11)
>>
>> Bob, could you confirm this?
>>
>> Regards
>> Pine.
>
> Hi Pine,
>
> This is correct. The length of RGs is properly determined by the values
> in the "rindex" system file, but 5 is very common, and is usually constant.
> (It may change if you used gfs2_grow or gfs2_convert from gfs1).
> The bitmap is 2 bits per block in the resource group, and it's relative
> to the start of the particular rgrp. You should probably use the same
> algorithm in libgfs2 to change the proper bit in the bitmaps. You can
> get this from the public gfs2-utils git tree.
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster