Bug 222308 - mkfs and journal addition for GFS2 should produce contiguous journals
mkfs and journal addition for GFS2 should produce contiguous journals
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs2-utils (Show other bugs)
5.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Robert Peterson
Cluster QE
:
Depends On:
Blocks: 221743
  Show dependency treegraph
 
Reported: 2007-01-11 11:00 EST by Steve Whitehouse
Modified: 2010-01-11 22:37 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2007-0579
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 13:04:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to allow contiguous journal allocation from mkfs (4.43 KB, patch)
2007-02-06 19:57 EST, Robert Peterson
no flags Details | Diff
Better patch to fix the problem (9.51 KB, patch)
2007-02-07 19:50 EST, Robert Peterson
no flags Details | Diff
Final patch to fix the problem (7.06 KB, patch)
2007-02-12 13:53 EST, Robert Peterson
no flags Details | Diff

  None (edit)
Description Steve Whitehouse 2007-01-11 11:00:46 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
close approximation.

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!
Comment 1 Robert Peterson 2007-02-06 19:57:46 EST
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.
Comment 2 Steve Whitehouse 2007-02-07 06:25:58 EST
Ok, it looks good to me, thanks for sorting that one out. Did you try testing it
against fsck?

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?
Comment 3 Robert Peterson 2007-02-07 19:50:39 EST
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.
Comment 4 Robert Peterson 2007-02-12 13:53:06 EST
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.
Comment 5 Robert Peterson 2007-02-12 14:03:24 EST
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
to modified.
Comment 8 RHEL Product and Program Management 2007-06-27 11:34:18 EDT
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
release.
Comment 11 errata-xmlrpc 2007-11-07 13:04:27 EST
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.

http://rhn.redhat.com/errata/RHBA-2007-0579.html

Note You need to log in before you can comment on or make changes to this bug.