Red Hat Bugzilla – Bug 222759
gfs_mkfs doesn't zero data after gfs superblock
Last modified: 2010-01-11 22:32:25 EST
Description of problem: gfs_mkfs doesn't zero out the entire page used for the gfs superblock and consequently the bytes after the superblock can be anything. These bits aren't really used for anything, but they look ugly when viewing with gfs_edit. Version-Release number of selected component (if applicable): RHEL5 How reproducible: Always Steps to Reproduce: 1. dd if=/dev/urandom of=/dev/trin_vg/trin_lv bs=1M count=16 2. gfs_mkfs -t bob_cluster2:bobs_gfs -p lock_dlm -j 2 /dev/trin_vg/trin_lv 3. gfs_edit /dev/trin_vg/trin_lv Actual results: Garbage after the superblock structure. Expected results: No garbage, rest of the page should be zeroed out. Additional info: This data was zeroed for RHEL4, but isn't for RHEL5. There shouldn't really be any consequences for customers here unless we decide at a later point in time to reuse some of those bits after the superblock and include them into the structure. I checked the other data structures, such as the rgindex, the RGs, the journal index, etc. All of them were zeroed properly, so I think this only affects the one block. Reported by Abhi Das. I recreated it on trin-10. I recommend we fix for RHEL5.1.
I verified this does not affect gfs2. The mkfs.gfs2 program does this zeroing of the data just fine.
Created attachment 145641 [details] Proposed patch to fix the problem One-line fix, tested on trin-10
Code fix committed to CVS at HEAD and RHEL5. Changing status to modified.
Fixing product name. Cluster Suite components were integrated into Enterprise Linux for verion 5.0.
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-0576.html