Description of problem: If you run mkfs.gfs2 on an existing file system, the first 16 blocks of the file system are not being zeroed, and they should be. If we don't, the leftover data in the new file system may be misinterpreted as what it was prior to mkfs.gfs2. For example, vfat and xfs both store their superblock at block 0. If we don't zero it out, someone could try to mount the gfs2 file system as the old type which will most likely panic the kernel. Worse yet, someone could run mkfs.gfs2 on a raw device that used to be part of an lvm volume, and they might in theory confuse lvm. Version-Release number of selected component (if applicable): RHEL5 How reproducible: Always Steps to Reproduce: 1. mkfs.vfat /dev/bobs_vg/lvol7 2. mkfs.gfs2 -t bob_cluster2:lv7 -p lock_dlm -j 2 /dev/bobs_vg/lvol7 3. mkfs.gfs2 -t bob_cluster2:lv7 -p lock_dlm -j 2 /dev/bobs_vg/lvol7 Actual results: On the second call to mkfs.gfs2, it says: This will destroy any data on /dev/bobs_vg/lvol7. It appears to contain a vfat filesystem. Are you sure you want to proceed? [y/n] Expected results: Should only be recognized as gfs2, not vfat: This will destroy any data on /dev/bobs_vg/lvol7. It appears to contain a gfs2 filesystem. Are you sure you want to proceed? [y/n] Additional info: Problem is in libgfs2, structures.c, function build_sb. The buffers for blocks 0 - 15 are not being updated.
Created attachment 141927 [details] patch to fix the problem Here's a patch to libgfs2/structures.c to fix the problem.
A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.