Hide Forgot
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.
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.
Abhi, are you happy with this patch? If so then we should get this in sooner rather than later I think.
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.
verified with ~18k files from kernel tarball + md5sum, 4k BS. None of the tested files was damaged.
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.
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