Bug 501732 - mount failure after gfs2_edit restoremeta of GFS file system
mount failure after gfs2_edit restoremeta of GFS file system
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs2-utils (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Robert Peterson
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2009-05-20 10:31 EDT by Nate Straz
Modified: 2010-01-11 22:43 EST (History)
2 users (show)

See Also:
Fixed In Version: gfs2-utils-0.1.57-1.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:02:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to fix the problem (799 bytes, patch)
2009-05-20 11:19 EDT, Robert Peterson
no flags Details | Diff

  None (edit)
Description Nate Straz 2009-05-20 10:31:58 EDT
Description of problem:

When a file system's metadata is copied with gfs2_edit savemeta and gfs2_edit restoremeta, the resulting file system does not mount:

GFS: fsid=kool:southlv.0: jid=0: Trying to acquire journal lock...
GFS: fsid=kool:southlv.0: jid=0: Looking at journal...
GFS: fsid=kool:southlv.0: fatal: filesystem consistency error
GFS: fsid=kool:southlv.0:   function = find_good_lh
GFS: fsid=kool:southlv.0:   file = /builddir/build/BUILD/gfs-kmod-0.1.31/_kmod_b
uild_/src/gfs/recovery.c, line = 179
GFS: fsid=kool:southlv.0:   time = 1242823112
GFS: fsid=kool:southlv.0: about to withdraw from the cluster
GFS: fsid=kool:southlv.0: telling LM to withdraw

Comparing the output of `gfs2_edit -p journal0 /dev/vg/southlv` on the original file system and the restored metadata shows:

--- south-01-southlv-j0 2009-05-20 09:06:15.000000000 -0500
+++ kool-southlv-j0     2009-05-20 09:17:08.000000000 -0500
@@ -1,5 +1,5 @@
 Dumping journal #0.
-0x12289c00 (j+   0): Log header: Flags:0, Seq: 0x4dd528, 1st: 0x12289c00, tail: 0x12291be0, last: 0x12290130
+0x12289c00 (j+   0): Log header: Flags:0, Seq: 0x4dd528, 1st: 0x12289c00, tail: 0x0, last: 0x0
 0x12289c01 (j+   1): Log descriptor, type 300 (Metadata) len:2, data1: 1
 0x12289c03 (j+   3): Log descriptor, type 500 (Final Entry) len:13, data1: 0

Version-Release number of selected component (if applicable):
gfs2-utils-0.1.55-1.el5, gfs2-utils-0.1.56-1.el5

How reproducible:
Every time

Steps to Reproduce:
1. create a GFS file system
2. gfs2_edit savemeta $dev foo
3. gfs2_edit restoremeta foo $newdev
4. mount $newdev /mnt
Actual results:
restored file system will not mount

Expected results:
restored file system should mount

Additional info:
Comment 1 Nate Straz 2009-05-20 11:03:22 EDT
Even after trying a patched version of gfs2_edit which saves the metadata so `gfs2_edit -p journal0` from the original and the restored file system has no difference, I get the same panic on mount.
Comment 2 Robert Peterson 2009-05-20 11:19:23 EDT
Created attachment 344827 [details]
patch to fix the problem
Comment 3 Robert Peterson 2009-05-20 12:13:02 EDT
The fix was pushed to the master branch of the gfs2-utils git
repository and the RHEL5 branch of the cluster git repository for
inclusion into 5.4.  It was tested on system "kool".  I have
cross-written the patch to STABLE2 and STABLE3 but not pushed them
yet.  Changing status to Modified.
Comment 4 Robert Peterson 2009-05-20 12:55:51 EDT
The fix is now pushed to STABLE2 and STABLE3.
Comment 8 errata-xmlrpc 2009-09-02 07:02:55 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.