Bug 545602 - gfs2_convert doesn't convert jdata files correctly
Summary: gfs2_convert doesn't convert jdata files correctly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs2-utils
Version: 5.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Abhijith Das
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 5.5TechNotes-Updates
TreeView+ depends on / blocked
 
Reported: 2009-12-08 22:23 UTC by Abhijith Das
Modified: 2010-11-22 23:29 UTC (History)
8 users (show)

Fixed In Version: gfs2-utils-0.1.62-18.el5
Doc Type: Bug Fix
Doc Text:
The jdata file conversion is not as efficient as it could be. If the gfs1 fs you're trying to convert has large (or a large number of) jdata files or the machine running gfs2_convert doesn't have enough memory, gfs2_convert will fail with a memory allocation error.
Clone Of:
Environment:
Last Closed: 2010-03-30 08:53:35 UTC
Target Upstream Version:


Attachments (Terms of Use)
First attempt at a patch (10.24 KB, patch)
2009-12-08 22:34 UTC, Abhijith Das
no flags Details | Diff
Fixes an error I spotted in the previous version of this patch (10.28 KB, patch)
2010-02-12 21:44 UTC, Abhijith Das
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0287 normal SHIPPED_LIVE gfs2-utils bug fix update 2010-03-29 14:05:15 UTC

Description Abhijith Das 2009-12-08 22:23:34 UTC
Description of problem:
When gfs2_convert is run on a gfs1 filesystem that has jdata files, the resulting converted gfs2 filesystem has metadata headers in the data blocks. This is due to the change in structure of the jdata data blocks on disk between gfs1 and gfs2. gfs1 has a metadata header for the data blocks whereas gfs2 doesn't.

Comment 1 Abhijith Das 2009-12-08 22:34:12 UTC
Created attachment 377031 [details]
First attempt at a patch

This patch duplicates a fair bit of code from the code-path that adjust indirect blocks of inodes. The difference being that it operates at the highest (data block) level and the metaheaders and data sizes per block are different at different heights.

This is not the most efficient way of doing this, but it works. It reads all the blocks of a file in memory while it operates and speed of execution depends on block size of the original fs, how much RAM is on the machine running gfs2_convert and the number of files and their sizes.

Comment 3 Steve Whitehouse 2010-02-10 14:58:20 UTC
Abhi, are you happy with this patch? If so then we should get this in sooner rather than later I think.

Comment 9 Abhijith Das 2010-02-12 21:44:37 UTC
Created attachment 390590 [details]
Fixes an error I spotted in the previous version of this patch

The earlier patch was attempting to convert the indirect blocks of exhash directories as well as regular jdata files. ExHash directories are of a different format than regular jdata files. This false conversion was causing gfs2_convert to fail later on with a "Error reading leaf 0" when it was trying to fix file and directory information. Although gfs2_convert reports a successful conversion, the resulting gfs2 fs is corrupt and will throw I/O errors and withdraw.

This updated patch leaves directories alone when trying to fix jdata indirect blocks.

Comment 14 Jaroslav Kortus 2010-03-04 15:45:37 UTC
verified with ~18k files from kernel tarball + md5sum, 4k BS. None of the tested files was damaged.

Comment 16 Abhijith Das 2010-03-10 17:24:09 UTC
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
The jdata file conversion is not as efficient as it could be. If the gfs1 fs you're trying to convert has large (or a large number of) jdata files or the machine running gfs2_convert doesn't have enough memory, gfs2_convert will fail with a memory allocation error.

Comment 18 errata-xmlrpc 2010-03-30 08:53:35 UTC
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 therefore 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-2010-0287.html


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