Description of problem:
When we did rhel5, we forgot to do the gfs2_grow function.
We need to add this. Some things should be easy because we can
use the same rg calculations that mkfs.gfs2 uses. The rgindex
should be updated via the metafs. The rg's can be written as
raw data with libgfs2, because the gfs2 kernel won't know about
them until gfs2_grow is done. The rindex update should be done after
the rgs are initialized, because according to Steve Whitehouse,
writing to the rindex through the metafs should cause gfs2 to
reread the index.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
-bash: gfs2_grow: command not found
A gfs2 file system should be extended as it does for gfs v1.
Created attachment 151803 [details]
First go at a patch
This is a big patch with several changes:
1. First of all, I moved a bunch of metafs-related code from main_jadd.c
to misc.c in libgfs2 so that the new gfs2_grow program could use them.
2. There's a new gfs2_grow.c program to extend the file system.
This was basically written from scratch and the old one thrown away.
3. I simplified the code and data structures by getting rid of
this whole idea of a "subdevice" for the mkfs-related programs.
4. I figured out a clever way I could simplify my life for bugzilla:
where gfs2_fsck has to repair broken RGs and rindex files.
Basically, the biggest pain regarding the repair of RGs is that
the "grow" code would change the RG size for the new portion added
to the file system. My solution is: Always have gfs2_grow figure
out the existing RG sizes and just keeping adding them in those
increments. That way, the RG distance will always be consistent
and gfs2_fsck can be more intelligent about its assumptions.
The down side of that is that if your original RG size was 2G, then
your lvresize needs to be at least that big so that the same RG size
may be used. You can't just lvresize a small amount of space, like
150MB and expect it to work. Some people may be unhappy about that,
but I think it's an acceptable limitation in order to allow fsck to
repair damaged RGs properly. This is more so an issue with gfs2 than
gfs1, because with gfs1, the journals were outside the file system
and predictable, so fsck could deduce extended pieces based on that.
With gfs2, the journals are inside the file system, so gfs2_fsck can't
make the same assumptions that gfs_fsck does.
5. I changed the libgfs2 function "compute_rgrp_layout" so that it
can work properly for both mkfs and grow. In other words, it can
now handle existing RGs when figuring out its calculations.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Because I moved a bunch of functions to gfs2_jadd to libgfs2, I discovered
yesterday that it also affected gfs2_quota as well, which had extremely
similar functions. So yesterday, I changed gfs2_quota to use the new
functions in libgfs2. Since I'm affecting all this code that Abhi Das
wrote, I'm adding him to the cc list to keep him informed.
I'll have to amend my patch to include those changes. I haven't tested
the new version of gfs2_quota yet, but it compiles.
Created attachment 153018 [details]
Patch for gfs2_quota
Here's the untested gfs2_quota patch that uses the functions
I ported from gfs2_jadd to libgfs2.
Created attachment 153888 [details]
Better patch for HEAD
This patch is the one tested with the gfs2_fsck_hellfire test case.
Created attachment 154555 [details]
RHEL5 patch to fix the problem
This is the RHEL5 equivalent patch. I needed to wait for gfs2_quota
to be resolved in the RHEL5 branch of cvs. It has been tested on trin-10.
Fix committed to CVS at HEAD and RHEL5 branches. Tested on trin-10.
Changing status to modified.
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 the 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.