ArchiveOrangemail archive

linux clustering


linux-cluster.redhat.com
(List home) (Recent threads) (164 other Red Hat lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 23,038 messages, beginning May 2004
  • 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Unformatting a GFS cluster disk

Ad
DRand1206470898Tue, 25 Mar 2008 18:48:18 +0000 (UTC)
This is a multipart message in MIME format.
--=_alternative 0067370980257417_Content-Type: text/plain; charset="US-ASCII"

Help!

We have accidentally formatted a GFS cluster with this command.

mkfs.gfs -J 1024 -j 4 -p lock_gulm -t aicluster:cmsgfs /dev/sda 

We were using the disk as a backup system. We need to unformat it.. Are 
there any tools that will let us get at the disk directory?

Damon.
Working to protect human rights worldwide

DISCLAIMER
Internet communications are not secure and therefore Amnesty International Ltd does not accept legal responsibility for the contents of this message. If you are not the intended recipient you must not disclose or rely on the information in this e-mail. Any views or opinions presented are solely those of the author and do not necessarily represent those of Amnesty International Ltd unless specifically stated. Electronic communications including email might be monitored by Amnesty International Ltd. for operational or business reasons.

This message has been scanned for viruses by Postini.
www.postini.com

--=_alternative 0067370980257417_Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Help!</font>
<br>
<br><font size=2 face="sans-serif">We have accidentally formatted a GFS
cluster with this command.</font>
<br>
<br><font size=3>mkfs.gfs -J 1024 -j 4 -p lock_gulm -t aicluster:cmsgfs
/dev/sda </font>
<br>
<br><font size=2 face="sans-serif">We were using the disk as a backup system.
We need to unformat it.. Are there any tools that will let us get at the
disk directory?</font>
<br>
<br><font size=2 face="sans-serif">Damon.</font>
<pre>Working to protect human rights worldwide

DISCLAIMER
Internet communications are not secure and therefore Amnesty International Ltd does not accept legal responsibility for the contents of this message. If you are not the intended recipient you must not disclose or rely on the information in this e-mail. Any views or opinions presented are solely those of the author and do not necessarily represent those of Amnesty International Ltd unless specifically stated. Electronic communications including email might be monitored by Amnesty International Ltd. for operational or business reasons.

This message has been scanned for viruses by Postini.
www.postini.com

--=_alternative 0067370980257417_=--
Bob Peterson 1206481880Tue, 25 Mar 2008 21:51:20 +0000 (UTC)
On Tue, 2008-03-25 at 18:47 +0000, wrote: > > Help! > > We have accidentally formatted a GFS cluster with this command. > > mkfs.gfs -J 1024 -j 4 -p lock_gulm -t aicluster:cmsgfs /dev/sda > > We were using the disk as a backup system. We need to unformat it.. > Are there any tools that will let us get at the disk directory? > > Damon.
Hi Damon, The short answer is no. There are no tools I'm aware of to "unformat" a gfs file system. However: Your ability to get back data depends on how the file system looked before the mkfs. If /dev/sda was ext3 before, I don't know what you can do to recover it. I do know that gfs and ext3 have their superblocks in different places, and I don't know ext3. The same pretty much goes for every other file system (xfs, vfat, etc.). If, however, /dev/sda was a gfs file system before the mkfs, then you stand a better chance of retrieving some data. If /dev/sda was NOT formatted with the exact same options to mkfs.gfs as before, (i.e. same rg size, same journal size, same number of journals) then your chances are very slim. If it were my file system, and I didn't have a backup, and I had data on it that I absolutely needed to get back, I personally would use the gfs2_edit tool (assuming RHEL5, Centos5 or similar) which can mostly operate on gfs1 file systems. The "gfs_edit" tool will also work, but it is much more primitive than gfs2_edit (but at least it exists on RHEL4, Centos4 and similar). Bear in mind that this is completely theoretical, dangerous, untested and likely to NOT work properly, but there is a slim chance it might. Before I started to mess around with this, I would make a block-by-block backup of the entire device so I can always go back to where I started. Something like: dd if=/dev/sda of=/home/bob/sda.backup bs=1M (Assuming you have enough space available in /home/bob/) Assuming that the file system is not mounted from any node in your cluster, I would use gfs2_edit to go through every entry in the rindex file, use "j" to jump to each of the resource groups and "F" to go forward to each of their bitmaps, and for each of those blocks, I would change every byte in the block map to 0xff. This would basically tell gfs that every single block is "in use" and is "metadata". Then I would run gfs_fsck with "-y" to see if it could sort it all out. It may run for a very long time, and you'll get thousands of messages saying that everything is in the wrong state. Anything it finds would probably get put into the "lost+found" directory, since the mkfs would have erased your root directory. I would probably leave the last resource group bitmap all 0x00, though, otherwise gfs_fsck won't have any place to allocate a new lost+found directory, etc. And if I got anything valuable back from it, I'd thank the deity of my choice. :7) Regards, Bob Peterson Red Hat GFS
Lon Hohberger 1206556314Wed, 26 Mar 2008 18:31:54 +0000 (UTC)
On Tue, 2008-03-25 at 16:54 -0500, Bob Peterson wrote: > On Tue, 2008-03-25 at 18:47 +0000, wrote: > > > > Help! > > > > We have accidentally formatted a GFS cluster with this command. > > > > mkfs.gfs -J 1024 -j 4 -p lock_gulm -t aicluster:cmsgfs /dev/sda > > > > We were using the disk as a backup system. We need to unformat it.. > > Are there any tools that will let us get at the disk directory? > > > > Damon. > > Hi Damon, > > The short answer is no. > There are no tools I'm aware of to "unformat" a gfs file system. > However: > > Your ability to get back data depends on how the file system > looked before the mkfs. If /dev/sda was ext3 before, I don't know > what you can do to recover it. I do know that gfs and ext3 have > their superblocks in different places, and I don't know ext3.
I don't know GFS, but block 0 of the partition is here the primary superblock is on ext3. Fortunately, ext3 stores a pile of backup superblocks throughout the disk - but I forgot the algorithm to determine what block #s contained them. > The same pretty much goes for every other file system (xfs, vfat, etc.). e2fsck -b [alternate_superblock_address] *might* help if you can figure out an alternate superblock location. Some of your data will be unrecoverable, and some will be unrecognizable (e.g. stored as a numbered file in /lost+found of the partition after e2fsck completes). -- Lon
James Chamberlain 1207162235Wed, 02 Apr 2008 18:50:35 +0000 (UTC)
On Mar 25, 2008, at 5:54 PM, Bob Peterson wrote: > If it were my file system, and I didn't have a backup, and I had > data on it that I absolutely needed to get back, I personally would > use the gfs2_edit tool (assuming RHEL5, Centos5 or similar) which can > mostly operate on gfs1 file systems. The "gfs_edit" tool will also > work, but it is much more primitive than gfs2_edit (but at least it > exists on RHEL4, Centos4 and similar).
Any idea what RPM gfs_edit would be in for RHEL4/CentOS 4? I've got CentOS 4.6, and I'm not finding it anywhere. Thanks, James
John Ruemker 1207168816Wed, 02 Apr 2008 20:40:16 +0000 (UTC)
James Chamberlain wrote: > > On Mar 25, 2008, at 5:54 PM, Bob Peterson wrote: > >> If it were my file system, and I didn't have a backup, and I had >> data on it that I absolutely needed to get back, I personally would >> use the gfs2_edit tool (assuming RHEL5, Centos5 or similar) which can >> mostly operate on gfs1 file systems. The "gfs_edit" tool will also >> work, but it is much more primitive than gfs2_edit (but at least it >> exists on RHEL4, Centos4 and similar). > > Any idea what RPM gfs_edit would be in for RHEL4/CentOS 4? I've got > CentOS 4.6, and I'm not finding it anywhere. >
AFAIK its not provided in RHEL4. In RHEL5 it would be in gfs-utils package. John
> Thanks, > > James > > -- > Linux-cluster mailing list > > https://www.redhat.com/mailman/listinfo/linux...
Bob Peterson 1207172348Wed, 02 Apr 2008 21:39:08 +0000 (UTC)
On Wed, 2008-04-02 at 16:38 -0400, John Ruemker wrote: > James Chamberlain wrote: > > > > On Mar 25, 2008, at 5:54 PM, Bob Peterson wrote: > > > >> If it were my file system, and I didn't have a backup, and I had > >> data on it that I absolutely needed to get back, I personally would > >> use the gfs2_edit tool (assuming RHEL5, Centos5 or similar) which can > >> mostly operate on gfs1 file systems. The "gfs_edit" tool will also > >> work, but it is much more primitive than gfs2_edit (but at least it > >> exists on RHEL4, Centos4 and similar). > > > > Any idea what RPM gfs_edit would be in for RHEL4/CentOS 4? I've got > > CentOS 4.6, and I'm not finding it anywhere. > > > AFAIK its not provided in RHEL4. In RHEL5 it would be in gfs-utils > package. > > John > > > Thanks, > > > > James
That's true, but I very recently (last week) built a gfs2_edit program that runs on RHEL4.6. (Yes, I know gfs2 won't run on 4.X but the gfs2_edit tool can still be used to work on gfs1 file systems.) I'm trying to get a people page worked out, and if that goes through, I'll post it there. I can send a tar/zip version of the source tree for this if anyone wants it. It's basically the same cluster source tree as 5.2, but I've modified it slightly so that it will compile on 4.6 without too much hassle. I can also easily send a x86_64 binary for RHEL4.6 gfs2_edit if that helps. A 32-bit version would be hard for me to build at the moment. The original gfs_edit is pretty primitive compared to gfs2_edit. Regards, Bob Peterson Red Hat Clustering & GFS
Home | About | Privacy