[Linux-cluster] gfs 6.1 superblock backups

[Bob Peterson]

On Tue, 2008-06-03 at 11:27 -0500, Chris Adams wrote:
> On Tue, 2008-06-03 at 11:03 -0400, Wendy Cheng wrote:
> Chris Adams wrote:
> > > Does GFS 6.1 have any superblock backups a la ext2/3?  If so, how
> > > can I find them?
> >
> > Unfortunately, no.
> >
> 
> If that is the case, then is it safe to assume that fs_sb_format will
> always be bytes 0x1001a and 0x100b on a gfs logical volume, and that that 
> is the only location on the lv that it is stored?  I see 
> #define GFS_FORMAT_FS (1309) /* Filesystem (all-encompassing) */
> and that is the location that where I see 0x051d (1309) stored.
> 
> thanks,
> -chris

Hi Chris,

As Wendy pointed out, there is only one copy of the GFS superblock.

You might be better off recreating the file system with gfs_mkfs
and restoring from backup.  If that option isn't available, read on:

The superblock itself is not too horrible to reconstruct, as long
as you know the block size (default is 4096).  The big question is:
did anything AFTER the superblock get destroyed?  A lot depends on
what was destroyed.  Immediately after the superblock is the first
resource group (RG) and its bitmaps, and if they got blasted, it
might be difficult to reconstruct your file system.  The newer
versions of gfs_fsck can repair a lot of these problems though, so
once you have a proper GFS superblock, you can give that a try.
If the RG was destroyed, gfs_fsck is likely to complain about a 
lot of things.

Right after the first set of bitmaps comes some important
system files: journal index, resource group index, etc.
If those got destroyed, it's even more difficult or even
impossible to get your file system back.  The quota file follows
and then the license file (now reused for fast statfs).  After
that is the root directory.  So you see, it all depends on what
all is destroyed and what is still intact.

If ONLY the gfs superblock got destroyed, you might be able to use the
gfs2_edit tool to patch in the correct values.  The superblock ought
to look something like this:

gfs2_edit - Global File System Editor (use with extreme caution)
Block #16    (0x10)           of 13092864 (0xC7C800)   (superblock)
(p.1 of 6)
00010000 01161970 00000001 00000000 00000000 [...p............]
00010010 00000064 00000000 0000051D 00000579 [...d...........y]
00010020 00000000 00001000 0000000C 00000010 [................]
00010030 00000000 00000016 00000000 00000016 [................]
00010040 00000000 00000017 00000000 00000017 [................]
00010050 00000000 0000001A 00000000 0000001A [................]
00010060 6C6F636B 5F646C6D 00000000 00000000 [lock_dlm........]
00010070 00000000 00000000 00000000 00000000 [................]
00010080 00000000 00000000 00000000 00000000 [................]
00010090 00000000 00000000 00000000 00000000 [................]
000100A0 626F6273 5F657878 6F6E3A65 78786F6E [bobs_exxon:exxon]
000100B0 5F6C7600 00000000 00000000 00000000 [_lv.............]
000100C0 00000000 00000000 00000000 00000000 [................]
000100D0 00000000 00000000 00000000 00000000 [................]
000100E0 00000000 00000018 00000000 00000018 [................]
000100F0 00000000 00000019 00000000 00000019 [................]
00010100 00000000 00000000 00000000 00000000 [................]
00010110 00000000 00000000 00000000 00000000 [................]
00010120 00000000 00000000 00000000 00000000 [................]
00010130 00000000 00000000 00000000 00000000 [................]
00010140 00000000 00000000 00000000 00000000 [................]
00010150 00000000 00000000 00000000 00000000 [................]

Everything after offset 0x150 should be zeroes on that block.
To get a breakdown of the superblock fields, press the "m" key.
For my example above, the field breakdown looks like this:

Superblock:
  mh_magic              0x01161970                (hex)
  mh_type               1                         0x1
  mh_format             100                       0x64
  sb_fs_format          1309                      0x51d
  sb_multihost_format   1401                      0x579
  sb_bsize              4096                      0x1000
  sb_bsize_shift        12                        0xc
  jindex ino            22                        0x16
                        22                        0x16
  rindex ino            23                        0x17
                        23                        0x17
  root dir              26                        0x1a
                        26                        0x1a
  sb_lockproto          lock_dlm
  sb_locktable          bobs_exxon:exxon_lv       
  quota ino             24                        0x18
                        24                        0x18
  license               25                        0x19
                        25                        0x19

The 'm' key is a three-way toggle, so you can get back to hex
mode by pressing it again once or twice.  The gfs2_tool is complex
and can be dangerous, so I don't recommend it for file systems
that are in production, unless your need is great.  Also,
never use it when the fs is mounted. The gfs2_edit man page tells
how to use it.  If this is a RHEL5 system or similar, you'll already
have the gfs2_edit tool available to you.  If this is RHEL4 you 
won't have gfs2_edit so your options are: (1) use gfs_edit which
is a primitive version  of the same tool, (2) I did a port of
gfs2_edit for RHEL4.  The source tree may be found at:

http://people.redhat.com/rpeterso/Experimental/RHEL4.x/

If you go this route, you would have to untar the file, then do:

.configure --kernel_src=/usr/src/kernels/(your kernel)
make
make install

This port assumes you have the kernel headers (i.e. kernel-devel)
rpms installed.  I hope this helps.

Regards,

Bob Peterson
Red Hat Clustering & GFS