Bug 1107238

The missed continuation blocks were all of type GFS2_METATYPE_LB and this patch gets them to print. The output could be improved on though, so feel free to modify it to your taste. (It's against upstream but will probably apply to RHEL7 too, at least.)

diff --git a/gfs2/edit/journal.c b/gfs2/edit/journal.c
index e012bc3..58e51a0 100644
--- a/gfs2/edit/journal.c
+++ b/gfs2/edit/journal.c
@@ -582,7 +582,7 @@ void dump_journal(const char *journal, int tblk)
                                           " [UNMOUNTED]" : "");
                        }
                        eol(0);
-               } else if (sbd.gfs1 && ld_blocks > 0) {
+               } else if ((sbd.gfs1 && ld_blocks > 0) || block_type == GFS2_METATYPE_LB) {
                        print_gfs2("0x%llx (j+%4llx): GFS log descriptor"
                                   " continuation block", abs_block, jb);
                        eol(0);

Created attachment 907327 [details]
Proposed RHEL7 patch

This patch seems to work nicely.

(In reply to Robert Peterson from comment #3)
> Created attachment 907327 [details]
> Proposed RHEL7 patch
> 
> This patch seems to work nicely.

I applied the patch (to upstream master), gave it a test and it looks good. The logic of the conditional makes more sense this way. Just a minor nit that the D in "descriptor" probably shouldn't be capitalized :)

Notes for QE:

# gfs2_edit restoremeta /home/bob/metadata/gfs2/savemetafile.meta.1026911.gz /dev/sasdrives/scratch

Without the patch:

# /sbin/gfs2_edit -p journal0 /dev/sasdrives/scratch | grep "continuation block" | wc -l
0

If the problem is fixed:
# /sbin/gfs2_edit -p journal0 /dev/sasdrives/scratch | grep "continuation block" | wc -l
71

Alternatively, you could devise a test that does a boat-load of
metadata manipulation such that at least one transaction has
more metadata blocks than will fit in a log descriptor. You need
504 metadata blocks or more for a single transaction. That will
create the necessary continuation blocks.

Requesting qa_ack.

Adding this feature to gfs2_edit is not a trivial matter. The
upstream patch doesn't apply directly because a lot of work was
done in the journal dumping code. All the journal dumping code
was separated out into its own source file, journal.c.
Here is a comprehensive list of commits I intend to push for
this bug:

-----------------------[ RHEL7.bob5 ]-----------------------
244856d gfs2_edit: Separate out the journal-related functions to journal.c
018cc79 gfs2_edit: Add more intelligence to journal dumps
a5a2ab2 gfs2_edit: Use the metadata description in get_block_type
6af44f9 gfs2_edit: Report referencing block address in the new journal code
9fb49f8 gfs2_edit: More static analysis fixes
7f198fc gfs2_edit: Corrections to log descriptor reference parsing
1adb7d6 gfs2_edit: mark log headers with the unmounted flag
9739f5b gfs2_edit: print LB (log descriptor continuation blocks) for GFS2
073cd78 gfs2_edit: Print block types with log descriptors

In reality, it shouldn't matter much, because we're planning to
rebase gfs2-utils for RHEL7 from the upstream anyway. So I'm
assuming this is okay. I tested all these on system gfs-i24c-01.

https://brewweb.devel.redhat.com/buildinfo?buildID=381969

Before fix:

[root@host-053 ~]# rpm -q gfs2-utils
gfs2-utils-3.1.6-13.el7.x86_64

[root@host-053 ~]# mkfs -t gfs2 -O -p lock_nolock -j 1 /dev/sda1
It appears to contain an existing filesystem (gfs2)
This will destroy any data on /dev/sda1
Device:                    /dev/sda1
Block size:                4096
Device size:               100.00 GB (26214055 blocks)
Filesystem size:           100.00 GB (26214054 blocks)
Journals:                  1
Resource groups:           400
Locking protocol:          "lock_nolock"
Lock table:                ""
UUID:                      c54c72ca-6b02-a9a1-2963-15f318cb4bbf
[root@host-053 ~]# mount /dev/sda1 /mnt
[root@host-053 ~]# dd if=/dev/zero of=/mnt/filler bs=1M count=30000
30000+0 records in
30000+0 records out
31457280000 bytes (31 GB) copied, 188.249 s, 167 MB/s
[root@host-053 ~]# sync
[root@host-053 ~]# rm /mnt/filler
rm: remove regular file ‘/mnt/filler’? y
[root@host-053 ~]# umount /mnt
[root@host-053 ~]# gfs2_edit -p journal0 /dev/sda1 > /tKtmp/j0.txt
[root@host-053 ~]# grep -c "continuation block" /tmp/j0.txt
0

After fix:
[root@host-050 ~]# rpm -q gfs2-utils
gfs2-utils-3.1.7-1.el7.x86_64
[root@host-050 ~]# mkfs -t gfs2 -p lock_nolock -j 1 -O /dev/sda
It appears to contain an existing filesystem (gfs2)
This will destroy any data on /dev/sda
Device:                    /dev/sda
Block size:                4096
Device size:               100.00 GB (26214400 blocks)
Filesystem size:           100.00 GB (26214398 blocks)
Journals:                  1
Resource groups:           51
Locking protocol:          "lock_nolock"
Lock table:                ""
UUID:                      b88d8568-baaa-7e96-119c-f31059b7d2d7
[root@host-050 ~]# mount /dev/sda /mnt
[root@host-050 ~]# dd if=/dev/zero of=/mnt/filler bs=1M count=30000
30000+0 records in
30000+0 records out
31457280000 bytes (31 GB) copied, 201.421 s, 156 MB/s
[root@host-050 ~]# sync
[root@host-050 ~]# rm /mnt/filler
rm: remove regular file ‘/mnt/filler’? y
[root@host-050 ~]# umount /mnt
[root@host-050 ~]# gfs2_edit -p journal0 /dev/sda > ?tmpK/tmp/j0.xKtxt
[root@host-050 ~]# grep -c "continuation block" /tmp/j0.txt
29

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0428.html