On Tue, Mar 18, 2014 at 8:08 PM, Bob Peterson <rpeterso@xxxxxxxxxx> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
