Bug 502056

Description of problem:
The gfs2_edit savemeta function currently does not save off
blocks of type 2, which correspond to "free metadata" in gfs and
"unlinked dinodes" in gfs2.  This turns out to be a problem because
if that metadata is restored and gfs is tested against it, it will
result in metadata allocation problems.  For example, gfs_grow may
make the decision to allocate a metadata block, and try to re-use a
block that's marked as "free metadata" in the gfs bitmap.  But
since the block wasn't saved at "savemeta" time, the block was
never restored as metadata and therefore the metadata header may
be missing, so gfs-kernel will throw a file system error.

Version-Release number of selected component (if applicable):
RHEL5.4

How reproducible:
Always

Steps to Reproduce:
I haven't actually tried this, but this should theoretically do it:

lvcreate -L 95G -n data roth_vg
mkfs -t gfs -j 1 -t "bobs_roth:data" -p lock_nolock -O /dev/roth_vg/data
mount -tgfs /dev/roth_vg/data /mnt/gfs
for i in `seq 1 1000` ; do cp /etc/fstab /mnt/gfs/f$i ; done
sync
rm /mnt/gfs/f*
umount /mnt/gfs
gfs2_edit savemeta /dev/roth_vg/data /tmp/bob.metasave
dd if=/dev/zero of=/dev/roth_vg/data
gfs2_edit restoremeta /tmp/bob.metasave /dev/roth_vg/data
mount -tgfs /dev/roth_vg/data /mnt/gfs
lvresize -L +200G /dev/roth_vg/data
gfs_grow /mnt/gfs
  
Actual results:

GFS: fsid=bobs_roth:data.0: fatal: invalid metadata block
GFS: fsid=bobs_roth:data.0:   bh = 62327 (magic)
GFS: fsid=bobs_roth:data.0:   function = gfs_trans_add_bh
GFS: fsid=bobs_roth:data.0:   file = /home/bob/cluster/gfs-kernel/src/gfs/trans.c, line = 290
GFS: fsid=bobs_roth:data.0:   time = 1242916713
GFS: fsid=bobs_roth:data.0: about to withdraw from the cluster
GFS: fsid=bobs_roth:data.0: telling LM to withdraw
GFS: fsid=bobs_roth:data.0: withdrawn

Expected results:
gfs_grow should work just fine.

Additional info:
I have a working patch to fix the problem.
Very low risk because gfs2_edit is only used for debugging file system
problems.