Red Hat Bugzilla – Bug 222308
mkfs and journal addition for GFS2 should produce contiguous journals
Last modified: 2010-01-11 22:37:06 EST
This is related to the layout of the journal on disk. In future versions of GFS2
I'd like to be able to represent the journal's block map as a series of extents
held in memory and read at mount time. It would be nice to have as few extents
as possible (ideally just one!) to store.
In addition, even with the current scheme, there are efficiency advantages to
having all the blocks in a "sensible" order. What I'd like to see is the following:
<inode> <indirect pointer blocks> <data blocks> (with no gaps between them)
Currently, if you grow a normal file through GFS2 then the indirect pointer
blocks get allocated at intervals throughout the data. It can be useful to keep
the indirect blocks close to the data blocks which they represent, but in the
journal case we can keep all the mapping information in memory all the time, so
that the important thing, is to keep the data as contiguous as possible to speed
up writing to the journal.
So the task is to check whether mkfs does this and if not, then to make some
changes to the way it allocates the journal. The other special files are
probably best left as they are for now.
Also when adding journals the following procedure should improve the layout (I'm
now assuming creating a file from userspace). After opening & creating the file,
lseek to the required size minus one byte, write that one byte, and then write
the rest of the file. That won't be as good as mkfs can do, but its a pretty
The only slight oddity in that case is that the final data block of the file
will end up just before the first data block, but since the journal is a
circular buffer, that shouldn't matter.
Let me know if thats not very clear and I'll try some ascii art!
Created attachment 147527 [details]
Patch to allow contiguous journal allocation from mkfs
This patch seems to do the trick, but it hasn't had a lot of testing.
You'll have to make libgfs2.a then relink mkfs.gfs2 to pick it up.
Ok, it looks good to me, thanks for sorting that one out. Did you try testing it
If that works and it appears to work ok with current gfs2 with various numbers
of journals then I guess the next stage is to get it into the FC package. Once its
been there for a little while I think we can then says its safe enough for RHEL5.1
Does that seem like a reasonable plan?
Created attachment 147620 [details]
Better patch to fix the problem
This version is better. It fixes a nasty problem plus it makes
gfs2_fsck call a common function in libgfs that mkfs also uses for
building the journals.
Created attachment 147922 [details]
Final patch to fix the problem
The previous patch caused a problem with gfs2_fsck writing too much data
when reinitializing the journals. This libgfs2 patch fixes that problem.
This one has had more testing and works for both mkfs.gfs2 and gfs2_fsck.
This one will be committed to CVS for HEAD and RHEL5.
Fix committed to CVS at HEAD and RHEL5. Both mkfs.gfs2 and gfs2_fsck
were tested on trin-10 using a variety of journal sizes. Changing status
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
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.