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