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