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!
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 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?
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 to modified.
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.
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