Bug 1017381

This is going to be a little tricky as we don't store the original requested rgrp size and with the latest mkfs work we might even expand some rgrps to accommodate single-extent journals. So it's always going to be best-guess (use the most common rgrp size ignoring ones containing journals?) unless we add an option to gfs2_grow to specify the rg size explicitly.

Well I hope that you can use the same functions are are being used in mkfs in order to size and location the new rgrps at appropriate points. That way it doesn't need to depend upon what is already on disk, and we can lay things out in the most efficient way.

We can use the same code but the problem is that, in mkfs.gfs2, we have the -r <rgsize> option to specify the base size of the rgrps and once mkfs.gfs2 is done, the rgrp size the user specified is forgotten because we don't store it (e.g. in the superblock like xfs does). We need that value to accurately work out the size of the resource groups before applying alignment and adjustment, and since we don't have it we'll always have to guess it in gfs2_grow based on what's already on disk.

I've been thinking about this some more and experimenting with some ideas and I've just about convinced myself that the new mkfs.gfs2 strategy of resizing the last couple of resource groups to fit on the device needs a rethink.

I wonder if it would be better to have a consistent resource group size (beyond the eventual specially-sized initial resource groups containing journals) such that, when the final resource group is placed, it would have the same number of bitmap blocks (i.e. the same ri_length) as the others but different ri_data, ri_bitbytes and rg_free fields, restricting gfs2's use of the bitmap blocks to only map the remaining device blocks. (I have a mkfs.gfs2 patch which does this.)

gfs2_grow could then rely on the last-but-one resource group having a representative size, and it could expand the final resource group to the same size due to there being enough bitmap blocks placed by mkfs.gfs2.

However I'm not certain that gfs2 would be able to deal with a) the possibly unusual mismatch between these fields and the number of bitmap blocks, and b) the growth of the final resource group in gfs2_grow. I'd like to get some feedback on those points. I guess the relevant question is, is it ok for gfs2_grow to increase the size of the last resource group while the fs is mounted, or is gfs2_grow limited to only adding new resource groups after the last one?

Patches posted upstream: https://www.redhat.com/archives/cluster-devel/2014-April/msg00053.html

There are 14 patches but some of them are quite small. They'll all be required as the fix depends on the libgfs2 rgrp API fixes and improvements which came before.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

(In reply to Ludek Smid from comment #7)
> This request was resolved in Red Hat Enterprise Linux 7.0.

Incorrect. If it was resolved it wouldn't still be in ASSIGNED state. Requesting the rhel-7.1.0 flag.

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

Created attachment 947006 [details]
Script for experimenting with gfs2_grow

I did some experimenting with different grow patterns and gfs2_grow appears to be doing the right thing.  As long as it can create an RG, it will and use all of the added space it can.   None of the old RGs are modified.  The new RG sizes are only based on the amount of space added.

Verified with gfs2-utils-3.1.7-1.el7.x86_64

[root@host-079 ~]# sh grow_ri_diff.sh nate 5G 50M 50M 1G 5G
--- create 5G LV ---
  Wiping gfs2 signature on /dev/nate/grow.1840.
  Logical volume "grow.1840" created
/dev/nate/grow.1840 is a symbolic link to /dev/dm-2
This will destroy any data on /dev/dm-2
Device:                    /dev/nate/grow.1840
Block size:                4096
Device size:               5.00 GB (1310720 blocks)
Filesystem size:           5.00 GB (1310716 blocks)
Journals:                  1
Resource groups:           4
Locking protocol:          "lock_nolock"
Lock table:                ""
UUID:                      4ec2452c-6c0f-2160-7040-a446d7101d91
=== Original rindex ===
RG index entries found: 4.
RG #0
  ri_data0              20                  0x14
  ri_data               32836               0x8044
RG #1
  ri_data0              32883               0x8073
  ri_data               425928              0x67fc8
RG #2
  ri_data0              458838              0x70056
  ri_data               425924              0x67fc4
RG #3
  ri_data0              884792              0xd8038
  ri_data               425924              0x67fc4
--- grow by 50M ---
  Rounding size to boundary between physical extents: 52.00 MiB
  Size of logical volume nate/grow.1840 changed from 5.00 GiB (1280 extents) to 5.05 GiB (1293 extents).
  Logical volume grow.1840 successfully resized
FS: Mount point:             /mnt/grow.1840
FS: Device:                  /dev/mapper/nate-grow.1840
FS: Size:                    1310717 (0x13fffd)
FS: New resource group size: 13315 (0x3403)
DEV: Length:                 1324032 (0x143400)
The file system will grow by 52MB.
gfs2_grow complete.
=== rindex diff 1 ===
--- /tmp/grow_rindex.dpOb/rindex.0      2014-10-14 14:14:46.058959121 -0500
+++ /tmp/grow_rindex.dpOb/rindex.1      2014-10-14 14:14:46.287959114 -0500
@@ -1 +1 @@
-RG index entries found: 4.
+RG index entries found: 5.
@@ -13,0 +14,3 @@
+RG #4
+  ri_data0              1310718             0x13fffe
+  ri_data               13312               0x3400
--- grow by 50M ---
  Rounding size to boundary between physical extents: 52.00 MiB
  Size of logical volume nate/grow.1840 changed from 5.05 GiB (1293 extents) to 5.10 GiB (1306 extents).
  Logical volume grow.1840 successfully resized
FS: Mount point:             /mnt/grow.1840
FS: Device:                  /dev/mapper/nate-grow.1840
FS: Size:                    1324031 (0x1433ff)
FS: New resource group size: 13313 (0x3401)
DEV: Length:                 1337344 (0x146800)
The file system will grow by 52MB.
gfs2_grow complete.
=== rindex diff 2 ===
--- /tmp/grow_rindex.dpOb/rindex.1      2014-10-14 14:14:46.287959114 -0500
+++ /tmp/grow_rindex.dpOb/rindex.2      2014-10-14 14:14:46.515959106 -0500
@@ -1 +1 @@
-RG index entries found: 5.
+RG index entries found: 6.
@@ -16,0 +17,3 @@
+RG #5
+  ri_data0              1324032             0x143400
+  ri_data               13308               0x33fc
--- grow by 1G ---
  Size of logical volume nate/grow.1840 changed from 5.10 GiB (1306 extents) to 6.10 GiB (1562 extents).
  Logical volume grow.1840 successfully resized
FS: Mount point:             /mnt/grow.1840
FS: Device:                  /dev/mapper/nate-grow.1840
FS: Size:                    1337341 (0x1467fd)
FS: New resource group size: 262147 (0x40003)
DEV: Length:                 1599488 (0x186800)
The file system will grow by 1024MB.
gfs2_grow complete.
=== rindex diff 3 ===
--- /tmp/grow_rindex.dpOb/rindex.2      2014-10-14 14:14:46.515959106 -0500
+++ /tmp/grow_rindex.dpOb/rindex.3      2014-10-14 14:14:46.735959099 -0500
@@ -1 +1 @@
-RG index entries found: 6.
+RG index entries found: 7.
@@ -19,0 +20,3 @@
+RG #6
+  ri_data0              1337358             0x14680e
+  ri_data               262128              0x3fff0
--- grow by 5G ---
  Size of logical volume nate/grow.1840 changed from 6.10 GiB (1562 extents) to 11.10 GiB (2842 extents).
  Logical volume grow.1840 successfully resized
FS: Mount point:             /mnt/grow.1840
FS: Device:                  /dev/mapper/nate-grow.1840
FS: Size:                    1599487 (0x1867ff)
FS: New resource group size: 436907 (0x6aaab)
DEV: Length:                 2910208 (0x2c6800)
The file system will grow by 5120MB.
gfs2_grow complete.
=== rindex diff 4 ===
--- /tmp/grow_rindex.dpOb/rindex.3      2014-10-14 14:14:46.735959099 -0500
+++ /tmp/grow_rindex.dpOb/rindex.4      2014-10-14 14:14:46.969959092 -0500
@@ -1 +1 @@
-RG index entries found: 7.
+RG index entries found: 10.
@@ -22,0 +23,9 @@
+RG #7
+  ri_data0              1599514             0x18681a
+  ri_data               436880              0x6aa90
+RG #8
+  ri_data0              2036421             0x1f12c5
+  ri_data               436880              0x6aa90
+RG #9
+  ri_data0              2473328             0x25bd70
+  ri_data               436876              0x6aa8c
  Logical volume "grow.1840" successfully removed

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